Developer Mindset - Reading Assignment

[filip]

[UPDATED TEXT & QUESTIONS] Time for a Reading Assignment, this time it’s about developer mindset and how it’s different from normal software development. Read this blog post(https://consensys.github.io/smart-contract-best-practices/general-philosophy/) and answer the following questions.

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?

[site]

1. I don’t know exactly. Audits, penetration testing, scans, keeping it up to date…
2. “The fundamental underlying nature of the Blockchain is to not be changed.” So don’t do it too much.
3. They should be like Helm’s Deep, a vary narrow and only entry way, easy to defend.

[bit]

How does the writer argue that banks protect traditional software from serious hacks?
banks centralised; there are layers of protection, some cards can be cancelled, others are maxed out, plus if a transaction does take place they can be traced and refunded. Whilst smart contracts are one way and final.

The writer is somewhat against upgradeable contracts, what arguments does he make?
Upgrading contracts could cause problems. Smart contract are desired to not change fundamentally towards the actual block chain or forwarded to gateways to action the most up-to-date contract.
basically simple & boring is better than complex and straightforwardness for maximum security

What comparison does the writer make between smart contracts and Lord of the Rings?
It only has one official entryway. This is because if enemies want to get in and plunder it, they need to climb up an extremely high wall, or a very narrow entrance. This design was prevalent in medieval times, as it makes it relatively simple for a smaller group of soldiers with spears to keep an entire army at bay by guarding a single opening.

Therefore the more complicated a smart contract it becomes, and as the complexity increases, so do the number of attack vector. In conclusion keep the smart contract simple so it is easier to defend. (reference “Helms Deep”)

[CryptoDragon]

1. customers can cancel their cards, many cards will be maxed out or don’t have balances. The thief cannot spend all money at once.
2. the fundamental nature of a blockchain is to not to be changed.
3. Helm’s Deep is a stronghold with only one narrow entrance which is easy to defend. The more entrance it has , the harder it is to defend. Smart contracts should also be simple, more complexity would allow more ways to be attacked.

[Dodd]

• How does banks protect traditional software from serious hacks?

Through obscurity - by hiding the details and limiting the access to the information.

1. Balance is known only by card owner on request
2. Card information can be modified (a client can block his card upon loss, etc.)
3. The funds and servers are secured “physically” (vaults, men with guns, etc)
4. Transactions are monitored and can be arbitrated (so that the money refund happens in case fraud was detected).

• The writer is somewhat against upgradeable contracts, what arguments does he make?

1. The immutable contracts are more “fair” and deserve more trust from the users.
2. The immutable contracts contain less error prone proxy logic (which might be exploited potentially)

• What comparison does the writer make between smart contracts and Lord of the Rings?

The contract should have as few things publicly exposed as possible. Similar to the castle design (both real and fantasy ones) which limits the number and amount of entrances.

[mattprime]

1. How does banks protect traditional software from serious hacks

Lifecycle for development of suhc applications includes methods to make sure software doesn’t contain bugs and to lower open attack vectors to system. Basically is traditional software protected from hacks on bigger scale also because of factors like: attacker doesn’t know exact amount which hold the card it was stolen (this makes very hard for him to stole complete money from card, because of many tries he need to make to withdraw complete amount of cash), transactions can be reverted and stolen money returned (insurance from insurance companies), attacker doesn’t know which stolen cards actually have any money on them (making them hard to retrieve money from big number of stolen cards, must make many retries)

2. The writer is somewhat against upgrade able contracts, what arguments does he make?

Upgrading contracts many times introduce errors in new code and opens new attack vectors.

3. What comparison does the writer make between smart contracts and Lord of the Rings?

Comparison is to create contracts like the stronghold Helm’s deep from movie.
There should be very few or just one entrance, which can be safely guarded.

[kato]

1. How does the writer argue that banks protect traditional software from serious hacks?
   Expire the credit card, empty the bank account or even retrace and cancel the transaction.
2. The writer is somewhat against upgradeable contracts, what arguments does he make?
   upgrade will lead to more problems.
3. What comparison does the writer make between smart contracts and Lord of the Rings?
   Their is only one way to approach the final destination in “The Lord of the Ring” and the way is narrow and hard to go through.
   A simple and straight-forward contract with less lines of code will be more safe because there will be less bugs.

[paul1]

1. Banks respond by having IT processes plus operational processes in place to prevent or minimize the effects of a hacking event. Processes such as blocking a card, monitoring for suspicious activities, card limits, card limits per transaction. also where the attack is on a card-by-card basis. So far more “limited” than say a cryptoattack.
2. that upgradeable contracts while very important can lead to inconsistencies creeping in over time, unlike a more boring or mundane contract
3. That having a contract with a one-entry point that is closely guarded is the key point, unlike having many entrances to such a castle/contract.

[xactant]

How does the writer argue that banks protect traditional software from serious hacks?
With insurance polices and reimbursing lost funds.

The writer is somewhat against upgradeable contracts, what arguments does he make?
The blockchain is meant to be unchanged and contracts which are changed often will cause suspicion and loss of trust.

What comparison does the writer make between smart contracts and Lord of the Rings?
Smart contracts should be built like Helm’s Deep with only a single heavily guarded entry way.

[Darren]

Is there any access to the slides pls?

[filip]

Which slides are you looking for?

[Jshanks21]

1. Even if banking software is hacked, clients can cancel their cards, freeze their accounts, or pursue reimbursement that is provided by most reputable banks. Additionally, if a user’s card or account is compromised, the hacker may not have access to the details of the account. As a result, they may not realize the account is worthless. It may also be possible to track the hacker’s activity in some cases.

2. He posits that smart contracts should be designed with lasting efficacy. Upgrading or changing a smart contract is more challenging to do because of the immutable nature of the blockchain. With this in mind, he argues that a smart contract that performs its intended functions while requiring fewer changes over time is superior to one that requires more.

3. He compares smart contracts to Helm’s Deep, a stronghold in the book, in that this stronghold only has one primary attack vector which is designed to only allow minimal assault from enemy forces. Similarly, smart contracts should minimize the access users have to its functions in order to reduce the potential attack vectors from bad actors. Because the smart contract code is publicly available, it’s safer to limit access to the smart contract to only it’s necessary functions. This way, even if an exploitable function is identified, there may be few or no ways to take advantage of it.

[Eric]

1 - They can roll back transactions.
2 - That the natue of blockchain is inmutability, and upgrading smart contracts often can lead to bugs
3 - With the abism of helm, in the way that you must to keep your entry points as minimal as posible in order to be able to control it.

[dave-dave]

1. How does banks protect traditional software from serious hacks?
   credit cards can be canceled, the thief does not know what is the balance in the accounts and it is impossible to spent all stolen money.

2. The writer is somewhat against upgradeable contracts, what arguments does he make?
   Changes are against the nature of the block chain.

3. What comparison does the writer make between smart contracts and Lord of the Rings?
   The fewer entry’s-the better-it is easier to defend… like in a castle.

[Guy]

1. How do banks protect traditional software from serious hacks?
   By protecting data in different layers/ different trusted cloud servers in a way that gives a lag-window to the bank and its clients to cancel and rollback transactions (cancel cards, freeze accounts, etc).

2. The writer is somewhat against upgradeable contracts, what arguments does he make?
   The fundamental underlying nature of the Blockchain is not be changed. For this reason, updating your contracts too often may cause more problems than it solves.

3. What comparison does the writer make between smart contracts and Lord of the Rings?
   The comparison is between the “one entryway” stronghold design in the Novell and smart contracts - as complicated it is, it harder to keep it safe ( more attack vectors/entryways are added).

[GoldenCryptoSupreme]

1. Why does smart contract development require a different mindset than regular programming?Smart contract development requires a different mindset because you must stay up to date in the new ecosystem, there is a high cost of failure since the code manages the money, and the difficulty of upgradability is inherently high with a blockchain so unanticipated bugs must be prepared for.

2. Argue with your own words why clarity in your code is more important than performance. It is more important for the code to have clarity so that you know exactly what will happen when it is executed. Code that performs well but has unclear functionality is of no value. There is a high cost of failure so bugs are more intolerable than reduced 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 is that they may believe that this is true privacy that protects the data from being seen. This is why it is important to only store sensitive data to the blockchain when necessary.

4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs? All fundamental principles come down to trade offs because for contracts of various applications and durations priorities are balanced between what is required for the structure and security. The theoretical ideals do not line up with the practical ideals so an effective compromise must be established.

[KamilK]

1. Smart contract development requires a different mindset than regular programming because of three main principles:
   a) The ecosystem is new (Smart Contracts and blockchain)
   b) High-risk development that deals with money and critical public data
   c) Smart contract are difficult to update
2. The clarity in code is more important than performance to make sure that potential bugs can be found as soon as possible.
3. The private data and functions are not accessible from outside (can`t be changed/called), but are still publically vieawable. Haker can study structure of our code and try to find pitfalls.
4. All the fundamental principles mentioned in the article comes down to tradeoffs because in many cases security and software engineering best practices may not be aligned.

[Erno]

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

Smart contracts are publicly visible and bugs are more difficult to fix than with regular software. So a bug could easily be exploited and while being hard to fix. That’s a dangerous situation. Furthermore are smart contracts in control of money, so the rist is also quire large.

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

Blockchain technology should not be used if performance is your key aspect. Blockchain is much better at security though. In order to keep the smart contracts as secure as possible, they should be easy to read (for other developers, or maybe users who are looking for transparency), easy to test, easy to debug and fix. In order to do so, responsibilities of functions and contracts should be as small as possible and really clear.

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?

One might think that private functions are not visible to the outside world at all. So someone who thinks like that might store valuable information like secret keys in a private function, which is really bad since those functions ARE publicly visible.

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

When writing a smart contract, sometimes one has to make trade-offs between security and software architecture. Most of the times these 2 principles will align and better code structure means a more secure smart contract. However, sometimes, one might have to stray away from the best practices in software engineering to allow a more secure contract.

[Dskeur91]

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

2. To guarantee security, your smart contract should be easy to test and to fix bugs when they appear. Beside that should they be easy to read and split code op in different contracts when you can. Beside that you should reuse code instead of duplicating it to maintain a clear structure with less possible problems to occure.

3. Private functions and private data are private in the sense that they are only accessible by that particular smart contract. The false beliefs are that the contract and these private functions and data are still public viewable there it is stored on the blockchain for everyone to see.

4. There always needs to be a balance between performance/flexibility and security, also in programming smart contracts. Probably for every point up for security you will hand in some points on performance or flexibility/possibilities.

[ProgPredator]

1. Why does smart contract development require a different mindset than regular programming?
   Because with smart contract our code is operating with money and has high risk of failure.

2. Argue with your own words why clarity in your code is more important than performance.
   To make our contact easy to read , to test and fixing the 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?
   All the code can be seen in the smart contact.

4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
   Because we need to find the balance between structure of the contract and its security.