Topic: Our first project on Ethereum: What we learned (Read 122 times)
Thanks!
Our first project on Ethereum: What we learned
We wanted to learn a great deal about Solidity, smart contracts deployment and web3 user interfaces.
To make things more engaging, we decided to build a standalone project, preferably something that could be done within one month.
Basically, if you want to make a decentralised app, you need to put both the business logic and the data on the blockchain. On Ethereum, you use the programming language Solidity and the resulting code which is a set of classes and methods and looks just like a regular program, is called a “smart contract”. Smart contracts are executed by the Ethereum blockchain nodes. Once you deploy your smart contract to the network and it gets confirmed, you can call public methods on your contract code. For every write operation, you pay a fee in Ether called “gas”.
One of us thought: how difficult would it be to create a reincarnation of the vintage concept of the Million Dollar Homepage, but this time, running on an Ethereum smart contract and a tokenised ownership of content cells?
We brainstormed this a bit and figured that we’d need an array representing the content cells and carrying the ownership and content information, a method for storing content, a method for retrieving content, a method for transferring the ownership of specific cells and an ERC20 compliant implementation for standard token transfers. Easy, huh?
We thought for a while what identity this project would get, and because we like *THE UNIVERSE*, a case study project called CRYPTOVERSE has been born.
(In case you don’t know or don’t remember: The original Million Dollar Homepage is a 2005 fundraising project by Alex Tew where people would buy 10x10 px cells and fill those cells with an image, a title and a hyperlink. The motto said “Own a piece of internet history” and it was a huge success. The website is still online as promised.)
Apart from the frontend, which is not very complicated, the whole project took us about a month to finish.
Before making CRYPTOVERSE, we only had an abstract knowledge of the Ethereum blockchain. Thus we had to dive into the basics. After learning about Solidity, Remix, Truffle, testrpc etc. we started putting together the smart contract that would handle the application logic.
It took us about three weeks to put everything in place including the “Welcome to Ethereum, developer” basics and a very good test coverage. (We had to figure out a lot of hidden corners that I want to talk about in a future post.) Then it took us another two weeks to find out how to create reliable tests for gas estimates, optimize the code, test it inside out on an Ethereum testnet, fix bugs and misconceptions and create a client interface.
You can see the smart contract code on Etherscan.
There are a few major areas we now understand much better.
1. No mistakes. Ever
One thing that’s very different from many classic deployment scenarios is that you don’t get to make mistakes on production. If you deploy a bug, there is no way to fix it except redeploying a separate new version and ask all concerned parties to accept the new contract on a new Ethereum account address.
That can be tricky especially when you, say, sell tokens (which is one of the most common applications of a smart contract nowadays). We’ve seen this situation a few times and all you can do is to throw away the old contract including all the transaction history it stored and try to migrate everyone, which may be thousands of people, cryptocurrency exchanges, 3rd party libraries etc., to the new version.
This is however one of the most important attributes of the network — no one can alter a deployed contract. That’s the reason why you can trust it: you get an Ethereum account address behind the smart contract, you inspect the code and if you agree on it, you can be sure it stays that way.
There is just no way around a test-driven development here. And be sure to test every single feature, every line of code, every negative scenario, every possibility. Your tests must be at least 10x longer than your implementation! 😄
2. Optimising
With high-level programming languages, we got used to forget about optimisations on line-to-line basis. Well, here we are getting back to the roots. Solidity is too a high-level programming language. You don’t deal with memory, but as the complexity of your smart contract or the amount of data it is carrying grows, so do the fees.
Get used to thinking in the terms of gas cost, pretty much the same way you may used to think about memory.
This sheet can help you analysing the cost of your contract code.
3. It’s all experimental
It was quite hard to grasp all the essentials and put together a working development environment. Since the technology is very young, we are still in a need of great “Getting Started” guides and community libraries that make adopting the technology much easier at the beginning. You need to scrape fragmented information and guides from multiple sources, and they are often outdated because things move fast.
Be prepared to encounter instability, bugs and breaking changes when dealing with client libraries and the network itself. Be creative when facing issues.
Also, don’t put all your stakes into an experimental technology. In November, a mistake in Ethereum wallet provider Parity caused a great amount of Ether (therefore dollars) to be frozen.
4. Some things are easy
A user backend is already there for you — an Ethereum enabled browser.
Having all the background knowledge, making CRYPTOVERSE could be even faster than using traditional tools.
MetaMask (an Ethereum wallet) is absolutely great and easy for developers but we need more “regular user”-friendly backends and processes. This is nonetheless a common theme in the cryptocurrency industry as a whole: How to make it more accessible and ready for a wide adoption?
5. Cryptokitties
Cryptokitties is a game that has its logic implemented on Ethereum and caused massive disruptions to the network latency and gas price. You can create something that get a massive attention, but you might accidentally break the network. It’s still young and scaling problems have not been resolved.
We postponed deploying our quite big and expensive contract because it was virtually impossible to have it confirmed to the network for a reasonable price.
6. The Future
To me, this is clearly the future. There is an enormous enthusiasm and effort going on around Ethereum. I don’t mean the global cryptocurrency hype but a real, honest effort to take technology into a next level.
Ethereum is not just another cryptocurrency, mainly, it’s a blockchain platform for running computer programs. Maybe Ethereum will get overthrown by a more progressive alternative but the concept as such will play a big role in the future of IT.
We wanted to learn a great deal about Solidity, smart contracts deployment and web3 user interfaces.
To make things more engaging, we decided to build a standalone project, preferably something that could be done within one month.
Basically, if you want to make a decentralised app, you need to put both the business logic and the data on the blockchain. On Ethereum, you use the programming language Solidity and the resulting code which is a set of classes and methods and looks just like a regular program, is called a “smart contract”. Smart contracts are executed by the Ethereum blockchain nodes. Once you deploy your smart contract to the network and it gets confirmed, you can call public methods on your contract code. For every write operation, you pay a fee in Ether called “gas”.
One of us thought: how difficult would it be to create a reincarnation of the vintage concept of the Million Dollar Homepage, but this time, running on an Ethereum smart contract and a tokenised ownership of content cells?
We brainstormed this a bit and figured that we’d need an array representing the content cells and carrying the ownership and content information, a method for storing content, a method for retrieving content, a method for transferring the ownership of specific cells and an ERC20 compliant implementation for standard token transfers. Easy, huh?
We thought for a while what identity this project would get, and because we like *THE UNIVERSE*, a case study project called CRYPTOVERSE has been born.
(In case you don’t know or don’t remember: The original Million Dollar Homepage is a 2005 fundraising project by Alex Tew where people would buy 10x10 px cells and fill those cells with an image, a title and a hyperlink. The motto said “Own a piece of internet history” and it was a huge success. The website is still online as promised.)
Apart from the frontend, which is not very complicated, the whole project took us about a month to finish.
Before making CRYPTOVERSE, we only had an abstract knowledge of the Ethereum blockchain. Thus we had to dive into the basics. After learning about Solidity, Remix, Truffle, testrpc etc. we started putting together the smart contract that would handle the application logic.
It took us about three weeks to put everything in place including the “Welcome to Ethereum, developer” basics and a very good test coverage. (We had to figure out a lot of hidden corners that I want to talk about in a future post.) Then it took us another two weeks to find out how to create reliable tests for gas estimates, optimize the code, test it inside out on an Ethereum testnet, fix bugs and misconceptions and create a client interface.
You can see the smart contract code on Etherscan.
There are a few major areas we now understand much better.
1. No mistakes. Ever
One thing that’s very different from many classic deployment scenarios is that you don’t get to make mistakes on production. If you deploy a bug, there is no way to fix it except redeploying a separate new version and ask all concerned parties to accept the new contract on a new Ethereum account address.
That can be tricky especially when you, say, sell tokens (which is one of the most common applications of a smart contract nowadays). We’ve seen this situation a few times and all you can do is to throw away the old contract including all the transaction history it stored and try to migrate everyone, which may be thousands of people, cryptocurrency exchanges, 3rd party libraries etc., to the new version.
This is however one of the most important attributes of the network — no one can alter a deployed contract. That’s the reason why you can trust it: you get an Ethereum account address behind the smart contract, you inspect the code and if you agree on it, you can be sure it stays that way.
There is just no way around a test-driven development here. And be sure to test every single feature, every line of code, every negative scenario, every possibility. Your tests must be at least 10x longer than your implementation! 😄
2. Optimising
With high-level programming languages, we got used to forget about optimisations on line-to-line basis. Well, here we are getting back to the roots. Solidity is too a high-level programming language. You don’t deal with memory, but as the complexity of your smart contract or the amount of data it is carrying grows, so do the fees.
Get used to thinking in the terms of gas cost, pretty much the same way you may used to think about memory.
This sheet can help you analysing the cost of your contract code.
3. It’s all experimental
It was quite hard to grasp all the essentials and put together a working development environment. Since the technology is very young, we are still in a need of great “Getting Started” guides and community libraries that make adopting the technology much easier at the beginning. You need to scrape fragmented information and guides from multiple sources, and they are often outdated because things move fast.
Be prepared to encounter instability, bugs and breaking changes when dealing with client libraries and the network itself. Be creative when facing issues.
Also, don’t put all your stakes into an experimental technology. In November, a mistake in Ethereum wallet provider Parity caused a great amount of Ether (therefore dollars) to be frozen.
4. Some things are easy
A user backend is already there for you — an Ethereum enabled browser.
Having all the background knowledge, making CRYPTOVERSE could be even faster than using traditional tools.
MetaMask (an Ethereum wallet) is absolutely great and easy for developers but we need more “regular user”-friendly backends and processes. This is nonetheless a common theme in the cryptocurrency industry as a whole: How to make it more accessible and ready for a wide adoption?
5. Cryptokitties
Cryptokitties is a game that has its logic implemented on Ethereum and caused massive disruptions to the network latency and gas price. You can create something that get a massive attention, but you might accidentally break the network. It’s still young and scaling problems have not been resolved.
We postponed deploying our quite big and expensive contract because it was virtually impossible to have it confirmed to the network for a reasonable price.
6. The Future
To me, this is clearly the future. There is an enormous enthusiasm and effort going on around Ethereum. I don’t mean the global cryptocurrency hype but a real, honest effort to take technology into a next level.
Ethereum is not just another cryptocurrency, mainly, it’s a blockchain platform for running computer programs. Maybe Ethereum will get overthrown by a more progressive alternative but the concept as such will play a big role in the future of IT.
Jump to: