How I was thinking before Web 3

I started my journey into web3 a few months ago. So, I am relatively new to web3, but I have many years of experience in software development in Web 2 and other software environments like desktop/mobile applications.

Being in web2 and other business-driven applications, the primary focus was already been to deliver solutions to businesses to let them function and earn revenue. Many IT managers I have worked with drive the agenda that business is the core function, IT is a support function and its job should be facilitation and should never stand in its way.

With that baggage in mind, many times, the best approach to software, the design principles of software and even testing takes a back seat. Especially where software solutions are outsourced and the agenda is to make things work.

All this happens because web2 allows us to change things, fix bugs and keep improving incrementally. We can even replace systems between users and data to deliver a better user experience.

Web3 does not give you chances like in web2, it is unforgiving

Web 3 does not let you do this.. yes, many would argue that we have a proxy design pattern to manage change, but it does not stand a chance to compare against what we were doing in web 2.

Web 3 application design can be thought of as comparable to aerospace design. After the vehicle is in flight, the flaw in design cannot be addressed. We can only hope that circumstances do not expose that flaw and that the flight reaches its destination.

So, Web 3 development demands the following

Respect Design principles

a) Prepare for failure

The cost of failure in Web3 is very high. As such, from the beginning, the development team should take a defensive approach to protect against any intrusion/attack.

b) Provision for upgradability in case a flaw is found

Ability to limit the damage in case the flaw is being exploited. Implement mechanisms to slow down or lock the vulnerable functions of the contract until the flaw is addressed.

c) Keep it simple

Complexity brings more flaws, so keep the implementation as simple as possible

d) Stay up-to-date with new changes

Always watch out for events like hacks, upgrades or research articles to ensure the development team has first-hand info about new vulnerabilities

e) Testing coverage

The development team should implement a testing suite to have full coverage for all smart contracts and ensure they covered all cases.

f) Auditing

Every smart contract, especially bearing financial risk should undergo an audit. The audit process gives chance for people from different mindsets the to review smart contracts and identify vulnerabilities.

Address known Vulnerabilities

The implementation team should carefully watch for the below vulnerabilities.

1) Reentrancy

Intra- and inter-function reentrancy attacks and potentially faulty solutions to them. 2) Oracle Manipulation

Manipulation of external data providers and potential solutions to oracle security issues.

3) Frontrunning

A definition and taxonomy around frontrunning and related attacks. Timestamp Dependence Attacks relating to the timing of a transaction.

1. Insecure Arithmetic Integer overflows and underflows.

2. Denial of Service

Denial of service attacks through unexpected reverts and the block gas limit.

1. Griefing

Attacks relating to bad faith players around a smart contract system.

1. Force Feeding

Force-feeding ether can cause manipulation of logic.

I am currently learning, it has been a very fascinating journey so far.