Dappology(Part 1)
Well, This was a heck of a venture for us, so we decided that it would be useful to share what we faced and how we tackled our issues to build decentralized apps on Tron Network; come with us in this venture:) This is the first series of Dappolgy. In the next parts, we will get more into practical documentations to write a Smart Contract and integrating it into your UI, but this part is high level abstraction of Dapps
Current Paradigm( How do centralized web apps work?)
As you might be familiar with how current web applications work, It has a client-side which connects to a back-end server (ASP.Net, for instance), and this server-side application handles the requests for different needs of your app(auth, payments, logs, etc.). I don’t want to dive into every detail of this architecture but let’s see where the problem is.
User Side:
First problem: How can you be sure that your data is safe and sound? What if this centralized app changes your data? This is a big deal. All the data is in their hand, and they can change your data by just a simple query in their database. Can you do something? Maybe yes and maybe no, so your only option is to trust them to treat your data well.
Second problem: How can you be sure that you and other users are treated equally in their web server and database? What if they decide that they don’t want to service your region? As it’s easy to observe, you and other users don’t know what is inside the box. They can easily put discrimination laws into effect and treat users differently by their Geo IP or gender or such ridiculous features.
Third problem: How can you prevent a monopoly when these apps get big enough to control their markets? What if PayPal(for instance) add 0.1 percent to its transaction fees? Obviously, those three major antitrust laws can’t and won’t stop any tech company to monopolize their markets. Again, you don’t have any option but to trust them not to do so ( and they had done and will do so).
Fourth problem: Censorship. Nothing is easier than censoring information in this kind of apps. They may be obligated to do so by authorities, or maybe that’s just their policy.
Fifth problem: It’s more expensive sometimes.
Developer Side:
First problem: Money, money, and money. Scaling a server is a rigorous task. You need to scale your servers horizontally and vertically, which demands not only technical expertise but also a huge amount of hardware resources. So your costs increase hugely as your users expand (that’s one of the reasons behind the fifth problem of user side)
Second problem: Law compliance and authorities. As a developer, if you don’t want your apps to get shut down, you have to comply with different countries’ rules ( and some of them are just crazy). Dealing with these authorities will cause depreciation of your app, and they can easily ban your service in their territories.
Third problem: Integrating a payment method can be painful( If you ever tried so, you would definitely agree with me). This is also a user-side problem that can cause many UX issues.
Honestly, I could go on and on and add more items to this list but let’s get back to our point that centralized paradigms have some problems(It’s, of course, your choice as a developer or user to continue to use this paradigm). OK, that’s enough complaints, let’s bring up some solutions(Hint: Dapp!)
What the heck is Dapp?
First of all, let’s clarify what Dapp stands for. Obviously Decentralized app. It is a web-based App -in our case-( it also can be a mobile-based app) that tries to use Blockchain(or any p2p consensus) instead of a routine back-end that we (as developers) and people(as users) all used to it for decades. As this world of Dapps seem interesting and revolutionary but we can feel that there is a lack of documentation for us to develop our apps on this robust platform(blockchain) unless you can read and write Chinese:)
In this world, there is no classic back-end. (almost) Everything is front-end. We will use the consensus between the nodes in the network to run an immutable code(called Smart Contract) with the same state(it acts the same as our old SQL databases). If you choose the right platform, then you can be sure that you have a free, scalable, secure, robust, resilient, fault-tolerant, and anti-censorship infrastructure that almost guarantees 100% uptime throughout the globe. (I assume you are now hyped up about Dapps)
Dapps … more than fancy words!
Django or any of your back-ends can be theoretically replaced with smart contracts but don’t forget that anything comes at a price. You can achieve huge throughput and astonishing reliability and transparency with blockchain. Still, you won’t be able to fix bugs in your contract, and you have to leap into the darkness(mostly because of lack of documentation).
Smart Contracts concept was invented back in the ’90s, almost a decade before Bitcoin, by Nick Szabo, and as of 2015, by the start of Ethereum blockchain, this concept can be practically used. Let me explain how this term works in practice and how much we need this technology in our daily usages: We all know Paypal, but why do we have to trust them or any of the payment services used worldwide? Have you ever read their back-end codes? Many questions come to our minds, but we ignore them because we don’t have any other options but fully trust these huge corporations. We are all aware of controversies around the US 2020 election. You might know some countries with a sh*t background in a democracy that calls themselves a democratic country:) Why do their people have to trust their system, which is so easily corruptible?
Dapp Architecture
Let’s elaborate on the architecture that we can use for Dapps. Same as before, we will have to design and build our apps UI, but instead of connecting it to your back-end, you have to connect it to your deployed smart contract with web3 or tronWeb(it depends on the blockchain that your contract is deployed on).
All the data is stored and secured in the network of nodes. These nodes will handle all the back-end logic, and all your scaling problems are solved by the blockchain that your smart contract is deployed on( I think it won’t fit in the abstraction level of this story to explain how these claims are promised).
Although you can(sometimes should) still use your back-end alongside your smart contract for specific needs that don’t need any consensus or transparency, and you are still be counted as a Dapp.
Dapp up/downsides
Upsides:
- Transparency in your app
- All the data is safe and securely stored
- Open-source is not a choice anymore. It’s a must
- No one can block your app (anti-censorship)
- Reduction of cost in developing and maintaining and scaling
Downsides:
- User experience is weak ( users have to use a wallet to interact with your dapp)
- Sometimes it can be slower
- Fixing bugs in your contract once deployed is (nearly) impossible
- Lack of development guide and documentations
- Expensive user interaction(each function call should be accompanied by a fee)
Tron is our chosen chain to use for Dapp!
There are plenty of blockchains that you can use them (if they support smart contract) to deploy your smart contract — Hyperledger Fabric, NEM, Waves, Ethereum, etc. Tron is our choice because currently, it’s one of the cheapest networks (it’s below 0.5$ even for most complicated contract triggers) with high throughput, and it’s also so similar to Ethereum, so it’s easy to go back to Ethereum when it’s PoS mechanism in v2 has taken place successfully.
Tron network has 27 Super Representatives(SR) that are re-elected by users votes every 6 hours. Each block is generated in 3 seconds, and each block has almost 50 transactions. We have to use the Solidity language to write our contracts, which will be explained in the next parts of Dappology.
Useful links
This is a tron explorer that you can find transactions and published contracts:
This IDE can be used to be used as a development environment:
This link contains useful documentations:
PS: Follow me so that you will be notified when we publish the next Dappology.
I have to thank Hadi Esna for reviewing this story. (He will be the author of the next Dappology, so Please follow him.)
Saber Zafarpoor is a blockchain engineer and product manager, and co-founder at OxyDev Consulting. OxyDev Consulting is a blockchain-based consultant and product development team, specializing in DeFi, BaaS, and Dapps in general. Before founding OxyDev Consulting, he worked for Cafe Bazaar and other tech companies.
He is a junior under-graduate of The Sharif University of Technology, where he will receive his B.S. in Computer Engineering.
You can connect with him on LinkedIn or Telegram or by visiting his personal website.
