Developer Mindset - Reading Assignment

[cyl2chan]

1.Why does smart contract development require a different mindset than regular programming?

SC dev is fairly new. So there shd be constant changes, since new bugs and security risks will emerge.

Cost of failure and change is difficult, which make it more like hardware programming and financial services programming than web dev.

2.Argue with your own words why clarity in your code is more important than performance.

If the code is complex, it increases the likelihood of error. Therefore it’s important that the logic of code is simple, and removes unnecessary code fragments.

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?

People may think that no one can view the private data and private functions, which may imply they think that private functions are less vulnerable to get hacked. However, private data and functions are also viewable by everyone.

4.Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?

You have to sacrifice one for another.

[shiv1]

1. Because in regular programming, it is easier to fix bugs and failure rate is not as high because most of the best practices have already been in place for years.
2. Clarity is better because you need your smart contract to be safe and secure than be high performance because smart contracts hold lots of money and you need to keep the smart contract safe as opposed to be high performance
3. Like Helm’s Deep. The small drain is easy to defend but if there were multiple, it would be harder. Same with smart contracts, the more complex it is, the more ways the smart contract can be attacked from, but if the smart contract is simple, it is less ways to be attacked.
4. Like Thanos and the knife he gave to Gamora, it needs to be balanced. If there is lot of performance and no security, it will be hacked, and people will lose a lot of money. If there is security and no performance, the smart contract will be slow.

[ClaususCatenae]

1. Why does smart contract development require a different mindset than regular programming?
   Because SC development is about creating applications, software and digital assets for (mostly) financial services (interacting with “money”), so not much room for failures, bugs, etc.
2. Argue with your own words why clarity in your code is more important than performance.
   clear code = easy to understand and to test = less bugs and less room for potential attacks
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?
   It may be misunderstood by thinking that private data is invisible, but it is not.
   4, Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
   We need to find the best balance between security & performance.

[Joeyj007]

1. Why does smart contract development require a different mindset than regular programming?
   Because 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.

2. Argue with your own words why clarity in your code is more important than performance.
   Coding is a clear and concise manner will most likely result in less errors when tested.

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?
   It is an open-source code so, nothing, is in fact private in a smart contract. Data can be called upon within the smart contract only and this may be susceptible to attacks.

4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
   It always comes down to security over performance in any case. Scaling can come at a later point in time once the smart contract is secure and bug free.

[Coffeenbourbon]

1. Why does smart contract development require a different mindset than regular programming?
   Because 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.
2. Argue with your own words why clarity in your code is more important than performance.
   Coding is a clear, concise, and law.
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?
   It is an open-source code any deployed smart contract can be read online.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
   It always comes down to security over performance in any case. Scaling can come at a later point in time once the smart contract is secure and bug free.

[Atlas]

Why does smart contract development require a different mindset than regular programming?

The cost of failure of a contract vulnerablility is high, and changes on the contract is not as easy as traditional programming methods, somehow requires hardware programming or financial services programming than web development.

Argue with your own words why clarity in your code is more important than performance.

Against scurity vulnerability of a smart contract requires more attention on bug fixing and remaining updated. To be able to update the contracts to the latest secure conditions and tracking bugs easily, so then keeping contracts simple and as primitive as they can be is crucial. Besides keeping code simple also means keeping contract away from multiple features signifies that it is reducing potentials of vulnerability that might be brought by the features.

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?

It would cause dangerous consequences that anyone who thought private functions are not viewable by public

Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?

Because of the principle that it is therefore not enough to defend against known vulnerabilities. Hence while the concept of decentralization requires fully freedom of designing a structure of a contract without limits to be creative and free, depends on the optimization between trade-offs.

[HAMMERTHOR]

1. Why does smart contract development require a different mindset than regular programming?
   Smart contract development requires a different mindset because:
   • The cost of failure is prohibitive.
   • Upgrading a smart contract is very difficult because its code is immutable. The code developer must be mindful of this at the onset.
   • A smart contract must be developed and tested to handle anticipated bugs and vulnerabilities.
   • Because smart contracts operate on a decentralized network, their design is different from that of a regular program.
   • Smart contract development requires that developers anticipate potential cyber attacks and take steps to prevent them.
   • The function of a smart contract is limited, unlike that of a regular program and developers must consider this in their design.

2. Argue with your own words why clarity in your code is more important than performance.
   Clarity in a smart contract code is more important than performance because
   • Clarity helps developers to maintain the code and it’s easier to make changes during development.
   • It makes code manageable and makes errors and vulnerabilities easier to spot.
   • It saves code development time and cost because clear code is easier to debug.
   • Unclear code makes it easy for a hacker to exploit its vulnerabilities.
   • A code written with emphasis on performance may be subject to vulnerabilities which compromise performance.
   • It’s easier and more efficient to maintain a clear code than a code written with emphasis on performance.

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?
   False beliefs someone might have around private data and private functions are:
   • Once private data and functions are deployed, they cannot be modified. This is not correct since they can be modified if they contain vulnerabilities.
   • Private functions are more secure. This is false because, unless the developer ensures the security of the private data and functions in the smart contract, they can be hacked.
   • Private functions and data can only be called by the contract owner. This is false because private contracts can be called by other contracts if invoked within a public function.
   • Private data is absolutely secure. This is false because a hacker can see a transaction before it is executed and change it in their favor.

4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
   The fundamental principles come down to tradeoffs because:
   • Smart contracts designed with a focus on ease of use may lack necessary security features and so, be an easy target for cyber criminals.

• Simplicity is particularly effective over complexity in cases where the smart contract system performs a very limited set of functionality for a pre-defined limited period of time, according to the article. This tradeoff is perfect for the specific smart contract described but not for a smart contract for a different task.

• Regarding the reuse of smart contract code in solidity, the article recommends “Using proven previously-deployed contracts which you own is generally the safest manner to achieve code reuse” and while the tradeoff is limiting, it makes sense when security of the smart contract is considered.

• The fundamental principles involved in designing a secure Solidity smart contract require consideration of the tradeoffs to ensure that a balance of security, functionality, complexity and usability result in a smart contract that meets the required standards of security while achieving the desired degree of efficiency and functionality.

[Tony_Siu]

1. Why does smart contract development require a different mindset than regular programming?

The cost of failure can be high, and change can be difficult

2. Argue with your own words why clarity in your code is more important than performance.

The code becomes less prone to error.

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 data is also stored in block chain. That is actually public.

4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?

Traditional software engineering goal is traded off for security

[SAINTPATRICK]

1. The cost of mistakes is way too high. Its much harder to correct mistakes in a smart contract/dapp than it is in other areas or development.
   2.Clarity in code is more important than performance because it makes it easier to spot coding eras and fix them. Also cleaner code could help with compilations.

2. 1. Belief that private data is completely secure: One false belief is that private data stored in a smart contract is completely secure and cannot be accessed by anyone else. However, it’s important to understand that all data on a blockchain is visible to anyone who has access to the network, even if it’s encrypted. If someone stores sensitive data in a smart contract under the assumption that it’s completely private, they could be putting themselves and others at risk.

3. Belief that private functions are inaccessible: Another false belief is that private functions in a smart contract are inaccessible and cannot be called by anyone outside of the contract. While it’s true that private functions are not part of the contract’s public interface, they can still be called by other functions within the contract. If someone assumes that a private function can only be called by the contract owner or trusted parties, they could be creating a vulnerability that could be exploited by attackers.

4. Because you’re always going to have to sacrifice one thing for another. life is full of trade offs.

[Marcio_Santana]

1. Smart contract development requires a different mindset than regular programming because smart contracts are immutable, public, and have high stakes. This means that any bug or vulnerability can be exploited by malicious actors and cause irreversible damage or loss of funds. Therefore, smart contract developers need to be more rigorous, cautious, and security-oriented than web or mobile developers.

2. Clarity in the code is more important than performance because smart contracts are meant to be transparent, verifiable, and trustworthy. If the code is obscure, complex, or hard to understand, it may raise doubts about its correctness, functionality, or intention. Moreover, unclear code may also introduce bugs or errors that are difficult to detect or fix. Performance is still important, but it should not compromise the readability or reliability of your code.

3. One false belief that someone might have about private data and private functions in a smart contract is that they are hidden from external observers or users. However, this is not true because all data and functions are public in a smart contract. Private data and functions only mean that they are inaccessible from other contracts, but they can still be read or analyzed by anyone who has access to the blockchain. This could have dangerous consequences if someone relies on private data or functions for sensitive information or logic that should not be exposed.

4. All the fundamental principles mentioned in the article come down to tradeoffs because smart contract development involves balancing different aspects such as security, simplicity, modularity, upgradability, and usability. Each aspect has its own benefits and drawbacks, and there is no one-size-fits-all solution for every situation. Smart contract developers need to weigh the pros and cons of each option and choose the one that best suits their needs and goals.

[fsicard]

1. Why does smart contract development require a different mindset than regular programming?

Smart contracts handle money and public information and are deployed on a public and immutable infrastructure (the blockchain)

2. Argue with your own words why clarity in your code is more important than performance.

Performance over clarity can open the door to potential attacks: code should remain easy to read, understand, debug, and fix.

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 term “Private functions” does not say that the functions are not public. It simply means that they can only be accessed by the contract it resides within, and not external contracts.

4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?

There is a balance between performance/flexibility, security, and clarity in smart contracts development.

[Alexlane8]

1. Why does Smart contract development require a different mindset than regular programming?

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 then web or mobile development. It is not enough to defend against known vulnerabilities. Learning a new philosophy of development is required. You must keep up to date on the latest developments and make sure your code is adaptable to improvements and debugging.

2. Argue with your own words why Clarity in your code is more important than performance

Clarity is important because you must ensure you pick up on and notice any bugs as soon as they occur because people’s money is involved. Simplicity is particularly effective over complexity in cases where the smart contract system performs a very limited set of functionality for predefined limited period of time. This Simplicity over malleability increases the security of the contract. It also optimizes the code review efficiency which is important for ensuring the Safety and Security of the contract.

Keeping functions small and using tools or code previously written minimizes the risk of mistakes in the contract. The contract has to be reliable and keeping the clarity over performance whenever possible helps ensure the smart contract does what it is intended to do minimize the risk of malicious code as well as spot any bugs that may occur.

Your code has to be adaptable because it must be able to respond to bugs and vulnerabilities as they occur. Your code needs to be able to pause the contract if things go wrong circuit breaker. Your code needs to manage money. Rate limiting and maximum usage. And your code has to be effective in upgrades for bug fixes and improvements

3. As the article says, all data and functions are public in the smart contract. What false beliefs might someone have around private data and private functions in a smart contract that could have dangerous consequences?

The public may not realize that the private data in smart contracts is viewable by anyone.

4. Why do you think all the fundamental principles mentioned in the article comes down to trade-offs?

An ideal smart contract system from a software engineering bias is modular, reuses code instead of duplicating it, and supports an upgradable components. However there are important exceptions where security and software engineering best practices may not be aligned. In each case the proper balance is obtained by identifying the optimal mix of properties along contract system Dimensions such as: Rigid versus upgradable. Monolithic versus modular. Duplication versus reuse.

[paradox]

The link to the article is no longer valid…

[JohnVersus]

Hi @paradox

Here is the latest link

https://consensys.github.io/smart-contract-best-practices/general-philosophy/

[Leo]

1. Why does smart contract development require a different mindset than regular programming?
Smart contract programming requires a different engineering mindset than you may be used to. 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.
2. Argue with your own words why clarity in your code is more important than performance.
Complexity increases chances of errors. Code clarity is of vital importance, considering the potential financial implications of vulnerabilities in smart contracts.
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?
Public functions are public, and may be called maliciously and in any order. The private data in smart contracts is also viewable by anyone.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
There are multiple fundamental tradeoffs 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 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.

However, there are important exceptions where security and software engineering best practices may not be aligned. In each case, the proper balance is obtained by identifying the optimal mix of properties along contract system dimensions such as:

• Rigid versus Upgradeable
• Monolithic versus Modular
• Duplication versus Reuse

[lawyer]

Why does smart contract development require a different mindset than regular programming?
Because of the exceptionally high cost of failure it entails, along with difficulties associated with correcting code mistakes.

Argue with your own words why clarity in your code is more important than performance.
Because the the benefits gained from code clarity (as it assists greatly in risk mitigation) are exponentially greater than those gained from code performance, given the aforementioned two issues (high cost of failure and difficulties in correction.) The smart contract development mindset must lean towards minimizing the potential for loss, rather than maximizing the potential for gain. The latter will still be obtained (albeit over a longer-term) if the former is properly addressed, and clarity plus risk mitigation leads to longevity of performance, thus a mature mission-critical mindset is the winner in this contest.

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?
Unlike in other development contexts, private data in smart contracts are viewable by anyone.

Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Because the principles mentioned are ones that modify the (generally speaking) default software engineering mindset and habits. They help the engineer to successfully adapt to the unique and intense demands of smart contract programming, through trade offs that mitigate risks and balance short-term inconvenience with long-term benefit.