You have a great idea for a decentralized solution to a problem. You know blockchain is the answer. You have started on the marketing, and you are now ready to launch the token sale. Now, a new question comes up: How are you going to execute, and which blockchain are you going to fork? Before you even choose a blockchain technology, there are questions that are vital not only in thinking about performance and fees, but in the viability and attractiveness of your token.
The considerations you should make, and your first consideration.
Since Dapp development is still in its nascent stages, the end user experience of your product becomes the ultimate story when making these decisions. First, you need to have a compelling product with a solid use case for the blockchain. Without a compelling product, it won’t matter what blockchain you choose. As with any application, you should absolutely have this figured out.
The three other considerations.
Working with blockchain technology comes with some great benefits: immutability, fraud prevention, decentralized consensus, and fault tolerance. The moment that you decide your product should be decentralized, you are already on the cutting edge of technology, and are advancing the way that we use technology to solve problems.
But this doesn’t mean that you don’t have anything else to think about. Performance, fees, and security become core ideas to consider as you develop your product on the blockchain. Even with the constant development of protocols to ensure a safe, secure, fast, and value-first experience, the development team can still make mistakes in any of these areas by not taking the steps needed to address these core issues.
Again, here are the key considerations:
- Security
- Performance
- Fees
Security has become a major issue, especially with the advent of Solidity (the language of the Ethereum Smart Contract), a highly used language in Dapp development. This is due to the developer being able to code a vulnerability into a contract, which, once deployed to the network, cannot be altered, which means that if there is a vulnerability in any method of the contract, it can be exploited. You may decide after research that you won’t use smart contracts, but, consider the popularity of Ethereum forks on token exchanges. You do need users and people buying your tokens, after all. There are other blockchains that use smart assets, or custom blockchains that use a hybrid model.
I would definitely recommend reading the Solidity docs thoroughly, practicing creating smart contracts, and committing to understanding and accounting for all possible vulnerabilities in your contract design and implementation. You should also identify someone on your team, or even better, a third-party consultant or solution to do security audits on your Dapp in a test network environment. And do not deploy a contract to a live blockchain, ever! Deploy to a testnet first and often. Whether you are creating a token or a more complex contract or contracts, using a testnet can help you identify vulnerabilities.
Performance is always tricky in the blockchain space since blockchain transactions do take a bit of time to execute. (This issue is also tied to the fees you’ll have to pay for a transaction, but we’ll get to that in a bit.) Currently, the Ethereum blockchain can only handle around 25 transactions per second (Bitcoin can only handle around eight). This is problematic when thinking about scalability and expanding the user base.
Performance of a blockchain is still in the hands of miners. Even though there are protocols in the works that may reduce the need for massive mining, that time is not coming anytime soon. You can be creative and utilize off-chain transactions to validate on-chain events, meaning you’ll have to really examine how your product works and what kind of transactions you’ll need to process on and off-chain. This choice will also force you to look at your architecture, and most likely will add time to your development process.
You can also identify creative hybrid solutions, such as Qtum (pronounced Quantum), which offers cross-platform development and an abstraction layer that would allow for more scalable secure smart contract implementation that may be more performant. You could also try to create your own hybrid solution, which would take quite a bit of time.
Hand-in-hand with performance are the fees. Fees are a reality of blockchain networks due to the need for mining to generate the currency needed to run these transactions. Eventually, mining will not be needed once all of the currency has been mined and is in circulation. (At least that’s one way we can hope for the end of high fees in an increasingly growing blockchain world where mining isn’t happening fast enough.) Keep an eye on when Ethereum’s Proof Of Stake protocol goes live (which should be sometime later in 2018). This fork could result in less need for mining and would speed up performance and reduce costs.
You can also look at alternative blockchains like NEM, which uses smart assets and a Proof Of Importance (POI) consensus protocol to speed up performance and keep fees reasonable. The one catch is that it is not widely used in the US, and is not listed as high as Ethereum. Creating a Dapp from a blockchain that isn’t Bitcoin or Ethereum is also a risk due to development familiarity and establishment of trust in the product being created.
The best way to make a great choice for your Dapp is to really understand what your product aims to do and how you can communicate it to your end users, including setting realistic expectations. Understanding that helps you find the right tools for the job, and isn’t that true in all aspects of software development?
