Author
The blockchain development cycle is, in the words of Tim Reznichenko, a senior full stack Web3 and TypeScript engineer and tech lead with K&C, “longer than it is for Web2”. That means it also intrinsically costs more – something that dApp project sponsors need to appreciate before they embark on a blockchain development project of any scale and complexity.
When Tim offers his insights and opinions on Web3 development, it is worth listening. He has been embedded with our partner Ajna Labs, an American DeFi startup, since early 2023 and previously founded a crypto exchange, LocalRelayer and a web development company.
He’s an experienced Web3 development leader.
Image: Tim speaking on Web3 development themes at a conference
Chatting about blockchain development challenges recently, we got onto the topic of why Web3 projects typically have a longer development cycle and cost more than comparable mainstream web development projects.
We decided:
- To detail a list of common technical challenges and Web3 ecosystem realities that he says “combine to prolong the Web3 development lifecycle”.
- He would share the lessons he’s learned over the years and several blockchain development projects about how to minimise the impact of these factors and make smart decisions.
With the salary levels of Web3/blockchain developers already at a premium compared to peers with mainstream web development stacks, longer development cycles mean higher costs.
The good news is that Tim is convinced current developments in the Web3 development ecosystem will significantly reduce the time and cost involved in dApp development over the next several years. As well as overcoming the common areas of UX friction that can drag on user numbers.
And that there are existing ways to mitigate many of the factors that add complexity to dApp development.
The technical decisions and challenges that add complexity to and prolong Web3 development life cycles
These are the big questions and more specific technical challenges and tripwires Tim has experienced as a blockchain development team lead.
Just being aware of them will give you a headstart over many Web3 development project funders and decision makers.
And Tim goes further – offering his insight into how to think about and mitigate these issues based on his experience across multiple dApp and blockchain projects.
The choice of blockchain to develop on always represents a security vs scalability trade-off
Web3 projects developed on blockchain technology are always, says Tim, faced with trade-offs between security, scalability and decentralisation.
Ethereum is the most popular blockchain to develop on, yet supports only 9-14 transactions per second. Other options like Solana and TRON can process transaction numbers in the hundreds or thousands per second but achieve that by making compromises on security and decentralisation that Ethereum doesn’t. Find out more about the specifications of different blockchains and their pros and cons in our blog post on blockchain platforms for smart contract development.
That compares to the tens of thousands of transactions per second traditional financial infrastructure providers like Visa and Mastercard can handle.
However, a root cause of Ethereum’s inherent limitations when it comes to scalability is, says Tim, that it “takes no compromises with security”. One of the Ethereum blockchain’s security strengths is the high level of decentralisation its extensive network of nodes provides.
Improved scalability means compromises with at least one of either security or decentralisation. This is known as the blockchain “scalability trilemma”.
The BNB chain, for example, is almost exactly the same as Ethereum’s blockchain. The only really significant difference, says Tim, is that the decentralisation side of the blockchain trilemma has been largely removed to allow for scalability – the chain is “basically controlled by Binance stakeholders and isn’t really decentralised”.
Solana, says Tim, is famous for “going down” and being unusable for as much as “a few days” every year because “they implemented some solutions that improved scalability and security but mean it now sometimes just gets stuck”.
L2 solutions like Polygon, Optimism and Starknet (Tim refers to it as “zk-STARK”) are blockchains built on top of core L1 blockchains like Ethereum. They make use of the underlying blockchain’s digital ledger but are not inherently decentralised as they can be controlled by a relatively small number of stakeholders.
He mentions the website L2beat.com, which he says is a good resource and ranks L2 solutions by metrics such as their transactions-per-second capacity, security and other qualities.
To mitigate concerns about true decentralisation, L2 blockchains usually provide much better performance. Security is provided by creating regular state snapshots on the underlying chain.The U.S.-based DeFi project Tim has been working on as part of an embedded K&C team was faced with the challenge of wanting to offer “multi-chain” access to their liquidity pools to give users a choice, creating less friction to adoption. They already have a deployment on Polygon but plan many more.
Because there is no interoperability between smart contracts on different chains, the dApps and blockchain protocols for each are practically independent of each other. There have to be separate liquidity pools – funds contributed by a lender using the Polygon dApp would not be available to a borrower using the Ethereum deployment or that on another L2 like Optimism.
A multi-chain approach means users can make their own decisions around the blockchain trilemma. For example, a lender contributing cryptocurrency worth hundreds of thousands or millions of dollars would be expected to prioritise security and opt for the Ethereum dApp.
Lenders and borrowers of smaller sums might, however, be willing to make some security compromises to use the Polygon deployment – because the L2 blockchain offers cheap transactions.
Bridges that link blockchains are an evolving solution to interoperability between multichain dApps reducing development complexity
Tim describes the scalability of dApps as closely linked to the evolving ecosystem of “bridges” that allow for interoperability between multichain deployments. Bridges, says Tim, mean multichain dApps can scale by using several blockchains and still offer a good UX.
Tim said a lot of new bridging solutions have been introduced to the Web3 development ecosystem in especially the past year. And that there are now a handful of stable SDKs that offer relatively convenient access to cross-chain functionalities and processes.
More out-of-the-box bridging solutions is one development helping make blockchain development more efficient. It is now more common to only have to integrate an existing bridging solution when before complex coding and tooling would often be necessary to achieve the same results.
UX challenges and considerations in blockchain development
Tim lists the following as particular sources of UX friction dApps often need to overcome to successfully scale their user base:
- Users need to install a special browser extension to use dApps.
- Users need to manually approve lots of functions they want to execute; and
- Pay fees in a blockchain currency they may not have.
Developing an dApp native to web browsers and mobile OSes necessitates integrating a proprietary wallet. However, developing a proprietary wallet introduces security threats and can represent a vulnerability if not done to the highest standards.
Is there a way to minimise or completely sidestep these common points of UX friction in dApps?
ERC-4337 account abstraction – an account abstraction proposal which completely avoids the need for consensus-layer protocol changes.
An Ethereum interface proposal that is a way to abstract the need for a wallet away from the user experience. That in turn allows the UX of a dApp to match that of a regular web2 app.
It allows a user to securely interact with a dApp without managing their private key, making the experience more native. It also includes the concept of sponsoring fees, which are instead covered by the dApp owner. It is, says Tim, comparable to how retailers cover Visa and Mastercard transactions as the cost of providing the convenience of card payments.
However, Tim considers the ERC-4337 solution as still “a work in progress”, and that dApp UX friction points still need to be managed as they currently are, obliging the user to tolerate them in the least painful way possible.
Tim expects this to change within around a year, with new solutions like ERC-4337 allowing dApps to move more of these current UX friction points “under the hood” and abstracted away from users. ERC-4337 and other proposed solutions still need some tinkering to perfect but are nearly there.
Avoid dApp UX disasters by using designers with prior experience and a strong understanding of blockchain and Web3
Tim highlights a reliance on UX designers who haven’t worked on dApps before or have a good understanding of Web3 as a potentially fatal mistake. One that he has seen lead to dApps that are “barely usable” and “not fit for purpose”.
Asked to provide a concrete example of what can go wrong when UX design does not fully appreciate the specifics of Web3, Tim instead offers a counter example.
The UX designer his team have been working with on our client project is, he says “a great designer and he understands crypto, really understands it. And he understands finance, which is also important. Domain knowledge as important to a UX designer is applicable to many domains. But with crypto, especially so.
The designer needs to understand technical aspects – like that transactions can take some time to complete. So the UX should clearly show and reassure the user that the transaction is in progress and is just taking some time – and nothing has gone wrong. For example, the dApp’s UI should show some kind of ‘in progress’ screen.
Crypto transactions failing, as Tim says they relatively often do for different reasons, is another thing UX design has to account for to ensure a positive user experience.
Apps offering traditional financial services, Tim gives the example of trading ETFs, have to deal with similar UX challenges around transaction processing delays and errors. However, these issues are exaggerated in the context of crypto markets.
Web3 developers have to contend with a less-developed ecosystem
Are you old enough to remember having to drive somewhere new and relatively far away before GPS navigation became standard? We had to rely on road signs, shouting questions at passersby out of windows and, as a last resort, maps.
Getting to a major landmark in a major city usually wasn’t very difficult, though it was much easier to miss the turnoff on a motorway. Finding a rural hideaway or a new restaurant in an unknown suburb? A recipe for disaster and the downfall of many a relationship!
The difference between Web3 and mainstream web development is comparable – in a loose “please be kind to my metaphor, I’m very proud of it” way.
Web2 developers can, says Tim, quite easily find a piece of functionality they need by Googling or searching in well known resources like GitHub or Stack Overflow.
In Web3 it is typically much harder. Even if someone has already built and shared something, it is often tucked away in an obscure corner of the internet. Like the repo of a minor hackathon or posted on GitHub by a research team that “has only 2 stars”.
The more niche the question, the harder it is to find a pre-existing answer. A bit like trying to find that holiday home at the bottom of a path that turns off from a village side street pre-GPS.
New AI (LLM) tools like ChatGPT and Bard, which has the advantage of being connected to the internet and a more up-to-date codebase, are one solution that Web3 developers are leveraging. But overall, the less developed Web3 ecosystem means that it takes longer to find pre-existing solutions and code when they do exist.
And it is far more common to have to develop solutions and code functionalities from scratch – which extends the Web3 development lifecycle and adds to costs.
TypeScript should be used in favour of JavaScript in Web3 front end development
Other than “exotic” edge cases, Tim says the choice of language for front end dApp development boils down to JavaScript vs Typescript.
Typescript has some qualities that help sidestep potential difficulties that can arise when using JS in dApp development, including being more secure and better supported by other tools and compilers thanks to being “strongly typed”.
More broadly, Tim says the need for math in front end development, which is often the case using JavaScript, should be avoided for financial apps.
This is because dApp back ends either don’t exist in the traditional sense, replaced by a blockchain, or they are limited and restrict options available to the development team.
This necessitates the need for developers to do some things like number aggregation and calculations that would normally be done on the back end, on the front end. Users have to see real numbers on the front end, not approximations or incorrect math – “and JavaScript is very bad at math”.
Getting around that limitation of JavaScript involves the use of BigNumber.js or another audited numbers library.
In conclusion, using TypeScript in favour of JavaScript for dApp front end development offers “more type safety”.
dApp UI development – React offers the richest ecosystem of blockchain-specific libraries and projects
The React library is the most popular choice for creating UI for dApps and offers the largest existing collection of blockchain-specific libraries and projects. But there is often the need to separate the presentation and logic/data layers of a dApp front end, In this case, frameworks like Next.js on top of React and Typescript are, says Tim, be a popular choice.
End-to-end testing is painful to create for Web3 applications
Writing unit tests for dApps is, Tim explains, more or less the same for Web3 and Web2 apps – but comprehensive testing that also verifies the correct integration between components is far more difficult in the Web3 context.
The complications around writing end-to-end tests for dApps come from the fact they need to use third-party wallets like MetaMask. This means tests also have to be integrated with third-party entities that are not part of the dApp.
This requires “a special set-up” involving a private blockchain because tests can’t be performed on public blockchains because they are immutable and there is no way to reset the state. So tests need to start from a snapshot of the public blockchain and go along the chain on a local blockchain that recreates the recent state of the underlying public blockchain.
End-to-end libraries like Cypress don’t support dApps out of the box. That means that plugins for integrations with Web3 entities like MetaMask need to be sourced or coded from scratch and frameworks extended to be able to meet requirements, which is again time-consuming.
A majority of dApps, says Tim, suffer from a lack of comprehensive end-to-end testing because it is so complex, time-consuming and expensive to set up.
When asked how the Web3 test tooling ecosystem is developing, Tim says the category needs to be divided into two:
- Tests for smart contracts
- Tests for dApps
Tooling for smart contracts testing is, according to Tim, currently improving at a rapid pace – “month on month”. There are, says Tim, already a lot of tools available for smart contract testing including test suites for rare cases like “fast tests” varying or extreme payloads – for Solidity and other popular smart contract languages.
When it comes to test tooling for dApps however, “there is not much movement”.
He believes there is a clear need for a library covering dApp tests and this is one of his personal points of interest. His response to my question of whether he will become “a dApp test library founder” is met with a chuckle and a “maybe, maybe”.
Security – you have to expect the worst because hackers target new dApps
Tim says dApp security, especially in the case of financial dApps should be an absolute priority – because hackers target new dApps, acutely aware that the additional complexity of comprehensive end-to-end testing means that it can be under-resourced.
Asked what measures dApp development teams can take to minimise security risks and heighten the defences built into their code and architecture, Tim notes one common tactic of hackers is to inject libraries with malicious code. If developers subsequently use compromised library components in a dApp, they would represent a backdoor for hackers to exploit.
To mitigate that risk he advises:
- The use of the most popular open source libraries like React, which have the resources to ensure the most secure ecosystems is one fundamental.
- Limiting the number of libraries is another key piece of advice “because each library offers a new angle of attack. Minimising their number is minimising the fronts that need to be defended”.
- Keeping libraries and software up-to-date with the latest patches and security bug fixes.
He also highlights that the “people” involved in any software development project, regardless of if it is Web2 or Web3, represent its greatest security risk. With this in mind, it is important to establish clear security guidelines and safety nets that cover the most common instances of human error.
One silver lining that Tim offers is that dApp attacks are “not that common” because hackers usually first target smart contracts. Another category of hacker approach is to manage to block the use of a dApp and demand a ransom to release it.
Deploying on CDNs and making sure all ports used for services on the back end are secured and whitelisting domains are all measures Tim suggests to mitigate these risks.
Staffing blockchain development teams with only full stack developers will improve efficiency
Tim recommends putting together development teams comprised exclusively of full stack developers able to work across the front and back end of a dApp project.
Asked why he sees full stack skills across team members as particularly important in a Web3 context he answers that dApps usually involve the development of a front end, SDK (software development kit) and a separate back end “to index blockchain transactions”.
The dApp front end and SDK should be written in the same browser-accessible language, usually TypeScript or JavaScript. And back ends that index blockchain transactions use subgraphs, which are written in AssemblyScript, “which is basically JavaScript – just a variation like TypeScript”.
This means that almost all the tools and technologies used in dApp development are “closely related to JavaScript”.
This JavaScript-centric quality of Web3 development lends itself to full stack development and reduces the need for different tech stacks.
Another advantage of full stack teams is that they are usually relatively small in the blockchain development space. All being full stack helps the team better communicate quickly and effectively with each other and flexibly allocate resources to the backlog – avoiding bottlenecks forming because only 1 or 2 people can pick up particular tasks.
Blockchain-powered dApps also don’t have “classical back ends” because the blockchain and smart contracts take on the role of the back end layer – or much of it. That means code written for the front end and SDK has to interact with the blockchain and involves complex logic and data aggregation.
Tim suggests that competent, efficient front end dApp development requires a full stack profile as the front end does more of the heavy lifting than in web development, which delegates as much as possible to the back end.
dApp UI testing takes longer due to more edge cases
Tim says comprehensive UI testing for dApps is also a longer, more complex process due to the larger number of edge cases that are typical compared to Web2 apps.
Asked why this is, he explains it is because smart contracts are not written for a single use case. Rather, smart contracts function like public APIs that can be used by many independent dApps as part of the smart contract chains that power their functionalities.
As a result, smart contracts are very general, which increases the risk of unexpected outcomes in edge scenarios.
The future of web3 and dApp development – expected trends
Which developments and trends does Tim expect in the Web3 development space over the next few years? Will the ecosystem develop in a way that will shorten the blockchain development lifecycle and help bring down dApp development costs?
In a word, yes.
Zero-knowledge proofs will reduce UX friction for dApps
Tim expects the introduction of improving zero-knowledge proof protocols into future generations of dApps will go a long way to reducing some of the common points of UX friction common to Web3 user experience.
Ethereum.org describes zero-proofs as:
“A zero-knowledge protocol is a method by which one party (the prover) can prove to another party (the verifier) that something is true, without revealing any information apart from the fact that this specific statement is true.”
For example, a zero-proof protocol could verify a loan applicant meets qualification criteria without giving the loan provider any further details on their finances.
Or verify that someone is over eighteen years old, without the authority checking minimum age requirements being given, or able to access, any more precise data.
Zero-knowledge proofs are based on complex cryptographic math and are not intrinsically connected to blockchain technology – though they are central to L2 scaling solutions. As explained by Ethereum.org:
“Zero-knowledge rollups (ZK-rollups) are layer 2 scaling solutions that increase throughput on Ethereum Mainnet by moving computation and state-storage off-chain. ZK-rollups can process thousands of transactions in a batch and then only post some minimal summary data to Mainnet. This summary data defines the changes that should be made to the Ethereum state and some cryptographic proof that those changes are correct.”
Tim believes in 5 or 10 years the technology will be widespread and replacing current identity verification mechanisms like 2-factor authentication, and as a means for law enforcement and other government bodies to verify needed information in a way that better respects an individual’s privacy.
In the Web3 context, zero-knowledge proofs will allow dApp users to make cryptocurrency transactions far more conveniently and securely. Currently, users need to provide their private crypto wallet keys to authorise transactions. That’s often clumsy in terms of UX and also represents a security threat.
Instead, believes Tim, zero-knowledge proofs will be used to prove that the user can access certain information, such as a private key, without revealing the key itself.
Other ways zero-proofs will help ease several areas of UX friction in dApps include access control and the kind of identity verification without revealing personal information that would be particularly useful in healthcare, finance, and government industries.
Smart contract programming languages
Tim highlights the growing popularity of the programming language Rust for writing smart contracts and also at the system level. Most blockchains themselves are written in Go(lang) and he expects that to continue, though Rust is also now used as an alternative.
Solidity, believes Tim, will continue to be the most common language for writing smart contracts in. The fact that it has a lot in common with JavaScript and TypeScript makes it relatively accessible to developers with existing knowledge in those languages. And, says Tim, it also benefits from the most developed ecosystem.
He says that if a dApp is being developed on the Ethereum blockchain or an EVM (Ethereum Virtual Machine)-compatible blockchain like Polygon or BNB Chain, the choice of language for smart contracts will be Solidity – unless there is a clear reason why and then the alternative choice will correspond to that reason.
If a dApp is being developed on Solana, smart contracts have to be written in Rust as that is the only language the blockchain supports. However, the blockchain has now developed a tool to convert smart contracts written in Solidity into Solano-compatible bytecode.
He expects more and better tools to convert smart contracts written in one language into other languages for other blockchains to be one trend in the Web3 development ecosystem over the next few years.
Tim also mentions that he expects more smart contracts to be written on the Bitcoin blockchain via L2 layers like Stacks in future. Bitcoin-hosted smart contracts became possible a couple of years ago to much hype and a lot of investment but interest has since, says Tim, died down.
If Bitcoin enters a new bull market, as he believes it might next year, Tim expects a new wave of interest in Bitcoin smart contract-powered dApps.
Tim personally sees Rust as an intrinsically better language for programming smart contracts than Solidity. Even if the latter was developed specifically for programming smart contracts, he thinks it “isn’t a great language for smart contracts”.
He explains this by explaining Solidity represents “some quite weird solutions in the context of an environment that needs to offer high levels of security”.
Rust meanwhile, despite being created as a systems-level language, not a smart contract language,gives coders low-level access and “incredible performance , as well as being very safe due to sophisticated type and memory safety. That adds another level of security because it means code written incorrectly won’t compile and work. And if it does, that intrinsically means it’s clean.
Rust, states Tim, “imposes discipline on the programmer”.
Despite that, he still believes Solidity will continue to grow in popularity due to its quickly growing ecosystem. He would also opt for Solidity in the context of most dApp projects for the same reason, even if security was a priority. He would compensate for this trade-off by devoting significant resources to writing comprehensive test suites to guarantee smart contract security.
Additionally, Rust-programmed smart contracts still need to be tested for functionality, even if the language’s qualities mean they will be intrinsically technically correct in their coding – and setting up testing for Solidity contracts is much easier.
He believes the ecosystem and tooling for the use of Rust in the context of dApp development will improve also but compares Solidity’s momentum to JavaScript’s in web development – he thinks the fact it is so much easier to read than the more complex Rust makes the barrier to entry lower. And will mean it continues to dominate, despite (also like JavaScript in his opinion) some of the technical deficiencies he sees.
As the Rust ecosystem improves it may well become the most popular language for smart contract programming in the context of dApps where security is a priority – its higher barriers to entry compensated for by the better security it offers.
The evolving dev ecosystem will significantly reduce the dApp development lifecycle
Tim expects the rapid development of the dev tooling ecosystem around dApp development and the greater availability of templates that simply need to be customised or extended will drastically cut down the time needed for many tasks in future years.
He also expects the blockchain development sector to have more focus on cross-chain solutions and L2 solutions to the scalability issues that dApps targeting a large market wrestle with.
But the good news is, the dApp development lifecycle can be expected to shorten and, with that, costs come down.
Tim Reznichenko – senior Web3 developer
Tim Reznichenko is an experienced Full Stack Engineer and Team Leader with over 8 years of expertise in delivering projects for US and European clients across multiple domains including Blockchain, AdTech, EduTech, LMS, CRM, SaaS, ERP, TMS, and Inventory Management.
He has led teams of up to 20 people and launched his own Decentralized Exchange and microlearning platform.
