1.- The special mindset for a smart contract developer comes from the fact that smart contracts handle money and thus this carries a risk, the ecosystem is new and evolving fast, and the immutability of the blockchain adds a layer of complexity when thinking about upgradeability.
2.- Clarity in the code is of higher priority because it allows to easily identify risks and bugs in the future.
3.- The false believe can be that private variables and functions are not readable to public, where in fact they are. Private only limits the accessibility of the variable or function. This means that if you store information in a private variable that is critical to the customer, like a personal ID or password, then this could be exposed to hacking.
4.- The tradeoffs come because of the various aspects a Smart Contract must satisfy. To optimize Gas Cost you can loose clarity. To make a contract upgradeable you can introduce security risk vectors, etc.
-
You need to expect constant changes in the security landscape due to new updates improving the integrity of a newly devised programming language like solidity. Furthermore, the cost of failure can be high when dealing with other peoples money and trust. It is not enough to defend against known vulnerabilities, instead to need to develop a new philosophy under the parameters of immutability, evolving ecosystem, and upgradability.
-
Clarity of code is more important than performance in that it allows you and other developers working with your code to identify or prevent against bugs and vulnerabilities.
-
False beliefs might be that private data is not viewable. This could lead to carelessness when developing and lead to risky and error prone code. Private data in smart contracts is viewable by anyone.
-
Tradeoffs between competing fundamental principles occur when deciding the functionality of your smart contract. You might decide the security management of your contract outweighs the traditional best practices that you are comfortable with. However, there are some tradeoffs that must be made in order to make your contract upgradable, simplistic when possible and modular. All without compromising security.
- Why does smart contract development require a different mindset than regular programming?
Because smart contracts deal with money, errors and vulnerabilties can have much higher impact than in less critical software. Besides, due to the concept of immutability it is much more difficult to fix bugs after the sc has been deployed.
- Argue with your own words why clarity in your code is more important than performance.
Security is the most important characteristic of smart contracts. And clarity obvioulsly helps a lot with attaining security. Besides, the etherium blockchain in rather slower anyway, so performance is not as important than in other types of software.
- 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 does not mean that the functions are not visible on the blockchain, so there should be no sensitive information in private functions.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Like in the real world you need to balance between extremes and must find a reasonable balance.
- Why does smart contract development require a different mindset than regular programming?
Because the cost of failure can be high (as it deals with money and trust), and a contract modification can be very difficult to make.
- Argue with your own words why clarity in your code is more important than performance.
Because complexity increases the likelihood of errors. Also it is easier to test and identify 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 is in terms of code (encapsulation). On the blockchain, all data can be seen. - Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Because to enforce a principle you need to take from somewhere else. there are always tradeoffs.
1. Why does smart contract development require a different mindset than regular programming?
Because you are essentially dealing with financial systems and money can be lost if the transactions are not done correctly or securely.
2. Argue with your own words why clarity in your code is more important than performance.
Smart contracts are dealing with currency that has value and so it is better to have code that works properly and securely. This way it can be read by the users of the smart contract and understood. It can also be updated later to work more effectively but in the end security is king.
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?
When declaring a function to be private the developer might believe that they can then store valuable information inside of that when it can actually be read.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
The main trade off would be security vs performance. Best performance practices might have to be dropped to allow for better security.
- 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.
clarity reduces complexity, makes it easier testable and readable, which helps on finding errors. The code handles money with that security should be the highest priority. Also is the blockchain itself rather slow.
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?
Anyone can see the code of the private data and functions, they still can be gameable over other public functions.
4.Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
because you always have to find a balance and you can’t have both
- Why does smart contract development require a different mindset than regular programming?
Smart contract development requires a different engineering mindset because Ethereum and complex blockchain programs are new and highly experimental. The cost of failure can be high, and change can be difficult. It is therefore not enough to defend against known vulnerabilities. Instead, you should expect constant changes in the security landscape, as new bugs and security risks are discovered, and new best practices are developed.
- Argue with your own words why clarity in your code is more important than performance.
You should keep your smart contract code clean and simple because complexity increases the likelihood of errors. 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.
- 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 dangerous to think that the private data in smart contracts is private and not publicly viewable. You must be careful what you put in private data since that data is viewable by anyone.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Depending on your smart contract use-case you must make tradeoffs in security and software engineering best practices. The proper balance needed for your use-case is obtained by identifying the optimal mix of properties along contract system dimensions such as: Rigid versus Upgradeable, Monolithic versus Modular and Duplication versus Reuse.
- Smart contract development requires a different mindset because it is closer to hardware programming or financial programming(two complex fields) then it is to mobile or web development.
- A performing programming is one that runs code without error. ALL non-trivial code will have an error at some point in the code, clarity in code enables your code to easily find errors when they persist and display in a simple format, therefore making it easier for other developers to collaborate on your code. It is better to have well-structured, clear code that is simple than complicated code that is not clear and prone to errors.
- When a function is private in a smart contract it applies to its functionality being private, not that the information embedded in the contract itself is private.
- It comes to tradeoffs because you can alot to take the path of simplicity vs complexity for example. Simple contracts are less prone to error but have limited capabilities. Malleable contracts are prone to error but have more functionality. Some other tradeoffs are modularity vs monolithic or duplicate contracts vs reuseable contracts.
1. Why does smart contract development require a different mindset than regular programming?
The cost of failure is typically much higher than in other branches of software development and it is very hard to update a contract once it is released (e.g. when a bug and/or vulnerability is discovered). This coupled with the constant change to the security landscape (given the new and rapidly developing blockchain technology) such as known vulnerabilities and the associated current best practices, means that a developer needs a mindset more akin to that of a hardware or financial services developer than say a web-developer.
2. Argue with your own words why clarity in your code is more important than performance.
If code is simple and straightforward it is easier to understand (and test). This results in fewer bugs (and probably fewer esoteric attack vectors) than more sophisticated, performant, and complex code. Since the risks and impact of failure are much higher with smart contract development (compared to general s/w development) it, therefore, makes sense to favour clarity, over performance, in smart contract code.
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 a developer (mistakenly) thinks private data and functions are publically viewable, then he may inadvertently expose private and sensitive data to the world at large. Also possibly providing further attack vectors that can be exploited with this sensitive information.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Whilst manly security practices align with general good s/w design principles of upgradeable, modular and reused code, there are security cases against each of these practices. For example:
- Upgradable code introduces complexity and therefore rigid/immutable may keep the code simple (and reduce security risks);
- Monolithic code, can give a very high locality of data and data flow, possibly aiding code review and keeping attack vectors lower than a highly modular design;
- Duplicate code may be preferable to code reuse if the code that code be reused is not your own, proven (battle-tested) code. There have been many vulnerabilities caused by developers using third-party code that turned out to be insecure.
Therefore it is not advisable to blindly follow ‘good’ s/w engineering practices but to also consider the counter security implications. This should result in adopting tradeoffs that are appropriate to your particular context and blockchain application.
1. Why does smart contract development require a different mindset than regular programming?
It have unique differences from regular development. It is still new, so many bugs and many best practices still have to be found. It is resource consumption sensible, you have to think about every byte of storage and focus on computational complexity.
2. Argue with your own words why clarity in your code is more important than performance.
Clarity is extremely important topic for smart contracts. Because that more readable contract is, it is much more easy to find bugs in it. Many people going to read your contract because it is public on chain. They could be your potential users, if contract logic is understandable there is higher chance they will be using your 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?
Fact that contract code publically available is very important to keep in mind. If you know it you will not store private data in contract storage.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
I think it is like universe balance. More complex application your have, more security risks you have.
-
Smart contract development requires a different mindset than regular programming because the cost of failure is high, the contracts are difficult to change once deployed and the fact that the contracts are managing people’s money.
-
Clarity is more important than performance because if it is perfectly clear exactly how each function works, and in what situations it should work and not work, then the code will be more resilient to any hacks or exploits unknown to the developer beforehand.
-
People might think private values and functions are not visible to everyone, whereas they are.
-
The fundamental principles such as upgradeability, modularization and reusability come with tradeoffs because one characteristic that makes a secure smart contract may directly affect another characteristic. Because of this, a balance must be obtained between the two as they are both important.
- Why does smart contract development require a different mindset than regular programming?
Because in many cases you are handling money, which is a big risk should anything go wrong. Additionally, modifying code or fixing bugs on Blockchain is more complex than in regular programming. - Argue with your own words why clarity in your code is more important than performance.
Because it makes code easier to understand and consequently, to maintain. - 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 might think that private variables and functions are really private in any sense. But the truth is that all the data on public blockchains is publicly accessable if you know how to. - Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
The application of each of those principles have benefits and drawbacks. Rigid code may be more predictable than upgradeable, but also vulnerable if any bug is discovered. Code reusability may be more efficient than duplication, but it could also bring vulnerabilities as in the BEC overflow bug.
- Why does smart contract development require a different mindset than regular programming? — this field of development is new and highly experimental, there’s constant changes in security landscape, best practices still being formed since cost of failure can be high, change can be difficult, and this makes it more similar to that of hardware programming or financial services programming than relatively “low consequence” style programming in web or mobile development.
- Argue with your own words why clarity in your code is more important than performance. —- performance means nothing is others cannot improve upon and spot vulnerability as vulnerabilities have a much higher cost if exploited than other systems
- 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 are “private” meaning they are not accessible by other contracts but that does not mean they cannot be seen and analyzed by possible attackers looking for vulnerabilities since the blockchain is public
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs? — there is a careful balance between security, performance, and centralization
-
Why does smart contract development require a different mindset than regular programming?
it is because it nearly impossible to upgrade smart contract code. Before deploying we have to make sure the code is fully audited and -
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: This requires a special mindset due to the nature of dealing with money. Many users need to be cautious before deploying as they need to keep searching for bugs!
2: Having clarity is quite important due to others reviewing your code. Also, the more complex the code is the more chance you have of vulnerability and attacks.
3: They might think nobody can see the private functions or data but being on the blockchain this information is public and they can look at the smart contract for possible hacks.
4: Due to the decentralized nature of smart contracts, you need to take into account for security, performance, but also how centralized parts of the project need to be. What needs to be in the contract and what does not.
-
Its because smart contract development is still at its early stages that’s why its very new and in that sense that’s what makes it very risky to develop at the moment and in the case of cryptocurrencies that has smart contract features it is more likely to deal with money, again its another big factor of risk since we are now dealing with money, and another point is that its very hard to update a smart contract once it is released and because of those issues that I mentioned, that’s the reason why for me it requires a different mindset compare to other regular programming that has already well established long history in the tech space.
-
Because the more your code is complex the more it is prone to vulnerabilities like errors, so its better to go for a simple code which is more easier to understood, easier to test and more easier to maintain, compare it a more complex code with better performance but its more harder for other developers to understand, so in the end you will find a hard time to look for other developers to collaborate with you, which will have a negative effect on the long term development of your smart contract.
-
The false belief is when a person believes that since it is called private data and private functions he/she might assume that it cannot be seen by the public, that is where the danger comes since a smart contract that is deployed in a public blockchain like the Ethereum blockchain the private functions and private data are all can be seen by everyone, which means that those functionalities can be a subject for exploitation.
-
Its because until now there is still no perfect way in coding a smart contract, so in either way you choose how to code weather you chose simplistic way or the complex way, there will always be a trade off between the two of them, so at the end of the day it will all depends on how the developers will come up to a proper balance between these fundamental tradeoffs.
- because of the complexities with upgrading, the possibility of bugs in the code losing money and the likeliness that any code you write will be attempted to be hacked
- simplicity in reviewing the code will make it easier for everyone to help find defects
- that private keys stored in contracts will be available for everyone to see, allowing anyone to drain the contract/wallet
- everything you do has tradeoffs, its best to understand the benefits and drawbacks of each and make the best decision
-
Smart contract development require a different mindset than regular programming because complex blockchain programs are new and highly experimental. Also, most importantly, smart contract handles money, and the code is very difficult to upgrade.
-
Clarity in the code is more important than performance because it makes code easier to read and find buys.
I have a habit of using less variables as possible but I should store key variables into another variable to make the code readable. -
Private data and private functions are viewable by anyone.
-
All the fundamental principles comes down to tradeoffs. Upgradeable contracts add potential risk to attackers. Modular contracts are hard to read (need to go back and forth). Reusing existing contracts can be dangerous if a bug is found.
-
Because Money is at Stake (code runs Money instead of Humans)
-
Logic, Mindset and Clarity have always been more important to Humans without which its impossible to achieve High Performance anyways.
-
The biggest false belief could be to think that anything that is declared “private” is somehow hidden and can only be read by the creator. Everything your smart contract does is exposed to the public.
Another point that is also crucial is that the whole processing of the data is public, meaning that you can’t even process sensitive data in a contract without exposing it to the public.
- This is a question on First Principles (everything in Life is a tradeOff against another thing in Life). The Triffin’s dilemma of Scalability, Security and Decentralisation is indeed 99.99% impossible to solve, so to overcome that 99.99% hurdle, we all have to make TradeOffs.
I also believe the approach of Ethereum is wrong, but it’s the biggest Blockchain with Network Effects. I rather feel that Solana with a simple Scalable design (and Scalability is damn important which most people discount) will be the winner of all Blockchains 5 years down the line , also its a little centralised at this moment (but will change in time- everything starts with Humans and their centralisation first) …
And have there been any bugs in Solana as yet ? No, because its based on an already established language #RUST (so lots of people’s collective energy has already been utilised to hone up and iron out the wrinkles)… This question is indeed Philosophical