- 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.Simple and clean code limits the likelihood of errors
3.Private data is still viewable to anyone
4.Just like everything nothing is perfect and what might help in one area could hinder another. When creating a smart contract a programmer needs to find balance with tradeoffs
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
Argue with your own words why clarity in your code is more important than performance.
- The code should be short, understandable and easy to read.
A long and complex code increases the likelihood of bugs and vulnerabilities.
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 wrong conviction could lead to personal data or private keys being stored in a smart contract.
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
- Decentralized smart contracts are still a new phenomenon. Therefore, the options and freedoms for programmers are still very limited.
But if you want to program a secure contract, you have to stick to these principles.
-
Why does smart contract development require a different mindset than regular programming?
It involves high cost of failure and the bugs are not easily fixed.
-
Argue with your own words why clarity in your code is more important than performance.
Because it will be easier to debug the code and upgrade.
-
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?
He/she might think that private data and private functions are not viewable by anyone.
-
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Because there are times when security and software engineering best practices do not aligned.
- Why does smart contract development require a different mindset than regular programming?
for the immutability of the information. An error can cost a lot. - Argue with your own words why clarity in your code is more important than performance.
Because the code can gain complexity when we need performance, this is not the ideal for the bugs. Simpler fewer bugs - 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?
All is public even all the date private data - Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
We need a balance between security and software engineer.
-
Smart contract development requires a different mindset because the cost of failure is high and difficult to make changes.
-
Clarity is more important than performance in code because having simple, clean code, that says what it does and does what it says, reduces of chances errors.
-
Public functions are called by anyone and private functions are restricted. It’s a false belief that private data in a smart contract will also be restricted from view but, private data is public.
-
All the fundamental principles come down to tradeoffs because the balance of security and performance is ours to find based on each use case.
1. Why does smart contract development require a different mindset than regular programming?
2. Argue with your own words why clarity in your code is more important than 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?
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
- new and quickly changing ecosystem, high cost of failure, difficult to upgrade
- clarity helps security and security is more important than performance
- someone might miss that data declared as private is still viewable by everyone outside the blockchain
- everything has pro and cons. Therefore, it’s most important to be aware of those.
- Smart contract programing requires a different mindset because the cost of failure is high and change is difficult.
- I think clarity in your code is more important than performance because adding complexity to your code to increase performance introduces additional opportunities for bugs or other unforeseen interactions. It is also much harder to troubleshoot and upgrade complex code.
- People might believe that their private data is protected on the blockchain when in reality all private data and functions posted to the blockchain are viewable by anyone.
- The fundamentals mentioned come down to tradeoffs because not all of the principals are best suited for every project and the ultimate goal or purpose of the contract should shape your decisions regarding the optimal mix of these principals and properties.
-
Why does smart contract development require a different mindset than regular programming?
Because the cost (financial) can be extremely high, and the ability to fix any issues after they have arisen can be quite difficult. -
Argue with your own words why clarity in your code is more important than performance.
Having code that is easily read is a benefit for others. It allows people to understand and follow what your code is doing. Additionally, if an issue is detected, it is easier to fix when people understand the code. A complex code that has incredible performance is good as long as no issues arise and needs no future updates (which is not ground in reality). -
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 be dangerous for anyone to assume that private data and private functions are fully protected and that there are no malicious actors actively trying to exploit any weaknesses. -
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
In reality, when issues arise, certain principles are more optimal than their counterparts. In some scenarios, the optimization may have the principles in reverse positions. Therefore, it is key to determine which principles are best for the circumstances and variables at hand on a vis-a-vis situation. In a nutshell, let the situation and circumstances determine which principles to use instead of allowing a particular set of principles to be ‘hard set’.
- Why does smart contract development require a different mindset than regular programming?
There is far more at stake to lose when bugs are exploited, which can involve large sums of value or even sensitive information
- Argue with your own words why clarity in your code is more important than performance.
It is better for code to be readable and understandable in order to identify potential attack vectors before they are exploited
- 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 making something “private” means the data or function is somehow encrypted and cannot be visible to others, which can reveal exploitation opportunities to malicious actors if extremely sensitive data is stored on the blockchain in this manner
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Because the nature of blockchain is immutable and irreversible by default, meaning that in order to make something mutable or reversible (which modern web development takes for granted) we have to add complexity that can expose weaknesses, and thus requires additional testing before launching. In this way, complexity trades off security and increases production time, and there could still be a bug hidden that nobody caught. Thus, we have to think about what we are willing to trade off versus what is needed by the contract, and the time duration we will need the contract for.
1. Why does smart contract development require a different mindset than regular programming?
Because it is a new technology with new environment, which is experimental and therefore is changing/upgrading a lot. Also when something fails it might be a big and serious problem. You need different mindset for this.
2. Argue with your own words why clarity in your code is more important than performance.
Because the more simple the code is the less probable it is that error occurs. Which can be much bigger problem than just worse performance. Also simple code is easier to fix, mainly for people who did not develop this certain 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?
Someone can think that private data and functions are not visible for anyone, but opposite is the truth.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Because everything has its pros and cons. For example malleability is very important for smart contracts, but it also brings more complexity and less security. It is good to choose such tradeoff which suits best to our case.
Why does smart contract development require a different mindset than regular programming?
Smart contract development requires a different mindset than regular programming made for centralized services because the cost of failure can be extraordinarily high.
To add to this, smart contracts have an element of immutability, so bugs can be exploited in perpetuity unless some contingency functions are put in place by the creators of the contract.
As the smart contract programming space is still very new and experimental, bugs are constantly being found and best practices change often.
Unlike traditional programs, smart contracts can be payable, and therefore it is common that billions of dollars can be locked into a contract.
If something goes wrong with the contract e.g. a bug is exploited, or a dependency on an external contract malfunctions, the value from a contract can be drained ($$$ lost), or the contract can seize to function, and the value sits in the contract forever.
These problems don’t exist in traditional programs. If a bug is exploited, the admins can quickly patch it and reupload the patched program. Whoever has admin access can freely make changes at any time.
Argue with your own words why clarity in your code is more important than performance.
There are obvious up-sides to both clarity and performance in code, however sometimes a programmer has to make a trade-off between the two. And there is not a one-size-fits all way to do things as contracts have differing utility, and hence sometimes it is better to sacrifice one for the other.
The Performance of a contract is convenient for the following reasons:
- Lightweight transactions are cheaper and faster
- A developer may be able to accomplish a wider variety of activities on a contract with better performance e.g. time-sensitive games/betting on a blockchain
Clarity in code is important for the following reasons:
- Other developers can interact more easily with your contract.
- Clear code will help the development team identify bugs before the contract is published
- Clear and modulated code allows for easier upgradeability
The trade-off becomes apparent if you are dealing with high amounts of value being held by the contract. If great deals of value are being held on a contract that doesn’t necessarily need to be actioned quickly, clarity will be of greater importance.
Here, clarity will add security and often it is worth having a clearer contract (e.g. something with more variables/functions) than one with better performance. The benefit of having a more secure contract which is a little slower and more of a gas-chewer can make up for the extra costs and latency in transaction speeds.
If you absolutely need quickly actioned lightweight transactions (which users interact with frequently), it can be better to sacrifice the clarity for optimal performance.
You may have to come to terms with the fact that you might have a contract which a developer introduced an attack vector whilst remodelling some process to improve performance.
As a general rule, less code is better. Super complex functions can introduce multiple attack vectors. And you should only submit data to a blockchain that needs to be. The rest is usually fine on centralised servers.
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?
Someone interacting with a smart contract could believe that because a function is private, they can add submit data to the blockchain that they want to remain private.
Just because a function is private does not mean the data submitted through the function is private.
Private functions can only be called by functions within the same contract, however the data that is submitted to the blockchain through private functions will still be accessible to anyone.
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Different horses for different courses. As with many things in life, you optimise for your specific purpose/utility.
It doesn’t take a galaxy-brain to realise that racing cars are not engineered to be optimised for fuel-efficiency or safety. Nor is a family-car optimised for speed and performance.
Generally speaking, the more valuable the goods inside the vehicle (or contract), the safer you want it to be - or in the case of smart contracts, modular and clear.
The fundamental principles in the article regard trade-off because they represent good properties in the hands of good people.
But where there are humans, there is greed.
And you have to remember that Trustless contracts are the phenomena in question.
There is a trade-off between upgradeability and malleability. Both are great features to have in decentralised applications.
But in a world where bugs exist, and rigid contract without malleable properties can quickly become an extremely dangerous contract.
Conversely, a functioning contract with upgradeable properties adds an an element of trust required for the admin.
Where an admin can upgrade a contract, they can upgrade it specifically to suit their needs. This can be as extreme as sucking all the funds from the contract and shooting it straight through to themselves . Thank you!
This defeats much of the novelty of what makes smart contracts so appealing.
1. Why does smart contract development require a different mindset than regular programming?
There are certain reasons that make smart contract programming different from regular programming-
-
The New ecosystem: Smart contract programming is a nascent space industry. Regardless of the platform, every day there are new updates in language, protocol, etc. As a developer, it’s vital to keep track of updates to deal with the unexpected.
Although the traditional programming languages need updates too, they are not as frequent as the former ones. -
High cost of failure: Sometimes the risk is very high in the development of smart contracts as they are very well capable of dealing with lots of money, public information. Again the developer needs to be heedful of his own work. While on the other side the stakes are not incredibly high as compared to the former.
-
Difficult to upgrade: A smart contract up-gradation requires a lot of effort. For upgradability a contract requires certain features without them a developer may need to stumble over new problems.
Not so difficult with regular programming.
2. Argue with your own words why clarity in your code is more important than performance.
Smart contract programming emphasizes clarity over performance. The Reasons could be-
- Less complexity
- Less prone to errors
- Easy to test, deploy
- More readability, understandability.
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 might believe that private data or functions can restrict visibility. Such beliefs can surely cause repercussions as they may unknowingly allow snooping of their data by storing private keys in private variables. It’s important to understand that private keyword is associated with accessibility, not visibility.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Tradeoffs incorporate a balance between the structure and security of a smart contract system. For instance, the rigidity of a contract can diminish its upgradability.
Therefore, tradeoffs maintain an optimal mix of these principles for an ideal smart contract system.
Why does smart contract development require a different mindset than regular programming?
Due to high failure cost, smart contract development is similar to hardware programming or financial services programming justifying the need for a new philosophy of development.
Argue with your own words why clarity in your code is more important than performance.
Clarity might be associated with easier debugging, reducing the risk of potential losses.
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 viewable by anyone.
Private functions can only be called from inside the contract, even the inherited contracts can’t call them.
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Simply put, the increase in a smart contract’s complexity tends to be inversely proportional to the security. So one must evaluate cautiously the number of features necessary to a given contract having in mind its impact on the contract’s security.
1. Why does smart contract development require a different mindset than regular programming?
With normal programming you don’t have existential risks. With smart contract programming people worldwide can view your code and try to attack it. So you have to be real careful with the contracts you are developing. With smart contract programming you gotta be prepared for failure that’s why you can pause the contract and halt it, wich you can’t do with normal programming. You also gotta think about how to manage all the money that is in the smart contract because there is real world value attached to the tokens that are inside of the contract.
2. Argue with your own words why clarity in your code is more important than performance.
It is almost essential to keep your contract logic simple because other wise it is very likely that there can be errors in the contract code and also harder to track it down. Because you are keeping the contract simple it also easier to test the 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?
private functions stay private but private data is still viewable to the outside world. with the private keywords it is about accessiblity not visibility good to know the difference.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs
Because with everything in programming/life there are trade offs to be made when you try to make you’re code immutable it has the trade off that it can’t be changed once it is on chain.
- Why does smart contract development require a different mindset than regular programming?
Ethereum and complex blockchain programs are new and highly experimental. Smart contract programming requires a different engineering mindset, 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.
- Argue with your own words why clarity in your code is more important than performance.
By knowing clearly what my code does I can improve performance more easily as I will be more clear what need to be done. Also if other developers clearly what my code does then can work on 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?
Private function means that function can ONLY be called inside the contract itself, but that doesn’t mean they are actually private.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
There are always exemptions where we can not apply an ideal smart contract system and that’s why it is recommended that any smart contract system identifies the proper balance of fundamental tradeoffs.
Developer Mindset Assignment
-
Smart contract development requires a different mindset because we are dealing with programmable money. The handling of public data as well as financial assets makes the cost of failure extremely high, and with the technology’s inherent properties, it is possible to develop and deploy an immutable contract, making it impossible to remedy exploits without the thoughtfulness to prepare for failure and design an adequate upgrade path.
-
When the cost of failure is this high, it would be wise to be cautious and clear in exactly what each particular function does. Making it easy to spot errors or potential exploits. Bugs thrive and hide in complexity while making it harder to identify problems before they occur. Clear and easy-to-follow logic should be the preferred course of action.
-
While private functions may only be called from the contract, the private data is still viewable; the private data could contain the logic for how the contract derives a random number thus enabling it to be gamed, or there could be time-lock features for something to take place at a given point in time, its possible for miners to manipulate the execution of the transaction. All of this can have disastrous effects with the false beliefs around private data and functions in solidity programming.
-
The fundamental principles come down to trade-offs because our contracts can be both rigid in structure or upgradeable, to the degree of which depends on exactly what’s being created so we can decide which of which to use and of what quantity.
- Smart contract development requires a different mindset because of the high cost of failure.
- Clarity in code is more important because it adds security by allowing it to be easier to debug and fix. This allows better readability of code for other developers and possibility more clear transparency for users.
- Private functions and private data are only accessible by that particular smart contract. That being said, it’s still viewable for everyone to see. Someone who doesn’t know this may store a private key on a private variable thinking that no one will be able to view the confidential information making the contract vulnerable.
- Because there needs to be balance between performance, security, and structure.
Answers
-
Smart contract development require a different mindset because, the cost of failure is very high and change can be difficult.
-
Clarity is more important than performance because, when debugging your code it is easier to read through it as well as other developers to understand it.
-
A consequence of someone having false beliefs on private data or functions can be that very important information can be viewed just because the function is private doesn’t fully protect it. It can be called by other functions within the contract that can give access to view that private information.
-
It all comes down to tradeoffs because it adds a balance on structure and the security of a smart contract.
-
Why does smart contract development require a different mindset than regular programming?
Because when dealing with smart contracts the risk of failure and cost to failure of a contract is imense. -
Argue with your own words why clarity in your code is more important than performance.
Keeping your code simple is more effective and can be read and understood by all users. -
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?
Misconception about private functions is that people think its ‘private’ in a sense that it cannot be called. But in actual fact it can be called from the contract itself using a public function.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Designing a contract that’s Flexible will decrease the security levels of the contract.
- Because smart contract development is new and you are dealing with real money
- We need safe
- These private variables or functions can are visible => there are many risks when they though that.
- We need more safe library like safemath so the contract is more complex but it should safer