Dive into Ethereum development. Part 0: blockchain is not needed
Surely many of you wondered why you needed a blockchain at all and Ethereum in particular. Someone may have gone further and found many beautiful characteristics: decentralization, transparency, trust without intermediaries, burglary. It's just great, right? Yes, but ...
The blockchain in its current form is ideal only for a narrow range of tasks, except for “adding nanotechnologies for the wow effect” task (and anything can be adjusted to this task). Of course, one must begin with something, various experiments probe the ground, show where demand can be expected, where an unexpected deadlock occurs, where shortcomings turn out to be not as critical as was predicted. But it is necessary to know about the borders in order to consciously decide whether in this particular case it is possible to try to step over them.
By the way, Ethereum is not the only and not the best option in all respects. Perhaps the blockchain just fits your task, but some other. But then we say “blockchain”, we mean “Ethereum”
Let's try to describe those features of the blockchain and smart contracts that make the solution of seemingly promising tasks ineffective or impossible at all. I would also like to say that the items are generalized, therefore, theoretically there may be quite normal solutions for specific use-cases. Therefore, treat this list as Ethereum weak points that need to be worked out before the project starts.
And also, please forgive if much of this seems obvious to you. As practice has shown, often it is about these things that one has to talk with the client in the first place.
If your audience is regular users, not blockchain-enthusiasts, then a very small part will bother to start using your application. Imagine: it is necessary not only to install Metamask or Mist with a node, but also to buy an ether, and this is also a nontrivial process at first. That is, if your goal is maximum audience coverage, then Ethereum is not suitable yet. For example, making a store solely on smart contracts is probably a bad idea.
Still, plus the blockchain is that participants may not trust each other as much as possible, but this is only possible if the user is the owner of his private key. Then only he can sign transactions and perform various actions from his address. What happens in the case of blockchain logic on the backend? The keys are managed centrally and there is no protection against transactions that are inconsistent with the user - it means that you just have to trust the honesty and security of the server. So for example, the majority of cryptobirds, although operating with cryptocurrency, do not use any related benefits.
Regardless of how the smart contract is written, if you wish, you can get the value of any data field in it. And transaction history. Therefore, if you write down something that identifies a user, such as mail or a name, then everything that makes this user becomes public. It is quite possible that you will have to wring some encryption over it. In this case, the keys for this will have to be stored on the receiving side, that is, the user must again entrust his data to a third party. Therefore, for more or less sensitive data, ordinary private storage may be more justified. If you are going to conclude agreements on the blockchain, you will probably lose more than you gain.
Someone may have the impression that the miners allow enormous powers to perform useful calculations, but this is certainly far from true. I would like to clarify just in case: the performance of Ethereum is more similar to the performance of the embedded system - limited resources, limited memory, limited size of the firmware (byte of the smart contract code). Therefore, non-critical calculations should be carried out to the maximum off-chain. For this reason, smart contracts are unlikely to be any difficult to analyze data or, say, encrypt
You can often hear the request to save something on the blockchain: information or documents. The problems are obvious here: firstly, saving data is expensive, secondly, the blockchain is not suitable for example — to search — either you have a mapping (key - value) which, by the way, also adds cost to each record, or you have to search for it. Plus there is no permission management. Therefore, you should not just change the database to the blockchain, it is important to understand why it was needed in principle. Separately, the files should be remembered about the publicity of the data: if you say you keep the link to IPFS, then everyone sees it and can download what lies on it. So if you want to store photos on the blockchain, you should think about why.
The blockchain itself transfers coins / tokens without problems, but how to transfer what is bought for them? Even if it is a file, how to ensure confirmation of its transfer without a third party? The short answer is: it’s not very easy, because we assume that both sides want to deceive each other and will be required to do a lot of checks, encryption and decryption, and if there is a dispute, you can’t do without off-line calculations or an arbitrator. As you know, for a physical product or service, everything is complicated by the fact that someone has to enter information that, roughly speaking, the product has been received. This someone can not be an interested person, then this is a third party, which we again have to trust. Then our blockchain solution has a weak place in the form of this arbiter, and since we trust him, why not trust everything else, let's say host the usual base and make payments. Before you do something you need to clearly answer this question. That is, for example, the meaning of the token, which you offer to exchange for a discount in an offline store, seems to us questionable
If you mistakenly sent money in the bank to the wrong place or your account was hacked, then you have the option to write in support, there is time to cancel or roll back the transaction. In smart contracts, you will not be able to manually do what is not provided by the code. Again we are faced with the need to introduce an arbitrator, who is granted privileges comparable to the centralization of the entire decision.
If you have a dynamic system with constantly rewriting states and logic based on them, then you probably will not be satisfied with the waiting time, since at least in Ethereum, a normal transaction confirmation time can be considered as half a minute, and if not to go broke for gas, it is usually longer. Even if the account does not go for seconds, consider the possibility of delaying the transaction for an indefinite time and laying down sufficient intervals. So while games like poker are either not possible on pure Ethereum smart contracts, or are non-trivial and require an emphasis on off-line logic.
If you want to oppose the government or something like that with the help of the blockchain, be aware that the web service is still a centralized thing, even though it is based on the blockchain. That is, the domain name or ip can still be easily blocked and users will need to know the address of the mirror. Advantages - you don’t need to make backups of the database and knowing the address on the Ethereum network, you can always access less user-friendly means (Mist, MyEtherWallet, etherscan, etc.) But you can’t say that the problem of censorship is completely solved.
Many who. Other blockchain and non-blockchain solutions may sacrifice either decentralization, or openness, or accessibility for an unlimited number of participants, in exchange for increased transaction speed, no privacy issues, etc. These are EOS, solutions for Hyberledger, Exonum, Hashgraph, Corda and more. But there is such an important factor as the name of the hearing. This is a large user base, and a large database of applications, information and development tools, tested. And this can be written in pluses to Ethereum. And let's see what Casper and Sharding will bring.
The most important issue going through all these points is the awareness of the choice of the blockchain. It is important that the technology solves the problem, adding a blockchain to an already solved task probably will not make the solution more effective.
For example, if you do not know who and you want to run a casino, then you have a problem to earn a reputation, show honesty and attract some kind of user base. By offering a solution on Ethereum, you can at least theoretically guarantee users a transparent job (although few people will actually audit your smart contract before the game). And attract people with extra cryptocurrency on the account and not enough opportunities to use it. We can say that the goal is achieved.
And if you want to add the blockchain to the messenger, then most likely not only do not solve the problems (and what they can be? - censorship and privacy come to mind), but also add new ones.
Finding more correct applications is probably a matter for the future, when the user base grows and it will be easier to buy cryptocurrency than now. But in general, you can look in the direction of such applications:
Affiliation of a task to one of the points does not mean that the blockchain will fit perfectly. Always see what other, more optimized technologies offer. That is, the line of thought should be “how to solve this problem,” and not “where to screw the blockchain.”
Diving into Ethereum development:
Part 1: introduction
Part 2: Web3.js and gas
Part 3: user application
Part 4: deploy and debugging in truffle, ganache, infura
Part 5: Oraclize
The blockchain in its current form is ideal only for a narrow range of tasks, except for “adding nanotechnologies for the wow effect” task (and anything can be adjusted to this task). Of course, one must begin with something, various experiments probe the ground, show where demand can be expected, where an unexpected deadlock occurs, where shortcomings turn out to be not as critical as was predicted. But it is necessary to know about the borders in order to consciously decide whether in this particular case it is possible to try to step over them.
By the way, Ethereum is not the only and not the best option in all respects. Perhaps the blockchain just fits your task, but some other. But then we say “blockchain”, we mean “Ethereum”
Let's try to describe those features of the blockchain and smart contracts that make the solution of seemingly promising tasks ineffective or impossible at all. I would also like to say that the items are generalized, therefore, theoretically there may be quite normal solutions for specific use-cases. Therefore, treat this list as Ethereum weak points that need to be worked out before the project starts.
And also, please forgive if much of this seems obvious to you. As practice has shown, often it is about these things that one has to talk with the client in the first place.
1. High entry threshold
If your audience is regular users, not blockchain-enthusiasts, then a very small part will bother to start using your application. Imagine: it is necessary not only to install Metamask or Mist with a node, but also to buy an ether, and this is also a nontrivial process at first. That is, if your goal is maximum audience coverage, then Ethereum is not suitable yet. For example, making a store solely on smart contracts is probably a bad idea.
What to do?
- Offering overlapping benefits
- Aim at the audience “in topic”
- It would be possible to hide the blockchain logic from the user, putting it on the backend, if not the next item
2. Decentralized centralization
Still, plus the blockchain is that participants may not trust each other as much as possible, but this is only possible if the user is the owner of his private key. Then only he can sign transactions and perform various actions from his address. What happens in the case of blockchain logic on the backend? The keys are managed centrally and there is no protection against transactions that are inconsistent with the user - it means that you just have to trust the honesty and security of the server. So for example, the majority of cryptobirds, although operating with cryptocurrency, do not use any related benefits.
What to do?
- Understand whether transparency and immunity or the ability to manipulate a crypt are necessary. If not, it is cheaper and more convenient to use a regular database.
- Think over and work out the mechanics of work so as to preserve technological guarantees
3. All data is public.
Regardless of how the smart contract is written, if you wish, you can get the value of any data field in it. And transaction history. Therefore, if you write down something that identifies a user, such as mail or a name, then everything that makes this user becomes public. It is quite possible that you will have to wring some encryption over it. In this case, the keys for this will have to be stored on the receiving side, that is, the user must again entrust his data to a third party. Therefore, for more or less sensitive data, ordinary private storage may be more justified. If you are going to conclude agreements on the blockchain, you will probably lose more than you gain.
What to do?
Understand whether private data is required for smart contract logic. If yes, consider the option of operating the hashes instead of the data itself.
4. Blockchain is not a supercomputer
Someone may have the impression that the miners allow enormous powers to perform useful calculations, but this is certainly far from true. I would like to clarify just in case: the performance of Ethereum is more similar to the performance of the embedded system - limited resources, limited memory, limited size of the firmware (byte of the smart contract code). Therefore, non-critical calculations should be carried out to the maximum off-chain. For this reason, smart contracts are unlikely to be any difficult to analyze data or, say, encrypt
What to do?
- Do not use blockchain as a calculator
- If you need calculations that are controlled on the blockchain, you can consider the feature computation in oraclize
5. Blockchain is not universal storage.
You can often hear the request to save something on the blockchain: information or documents. The problems are obvious here: firstly, saving data is expensive, secondly, the blockchain is not suitable for example — to search — either you have a mapping (key - value) which, by the way, also adds cost to each record, or you have to search for it. Plus there is no permission management. Therefore, you should not just change the database to the blockchain, it is important to understand why it was needed in principle. Separately, the files should be remembered about the publicity of the data: if you say you keep the link to IPFS, then everyone sees it and can download what lies on it. So if you want to store photos on the blockchain, you should think about why.
What to do?
- As a rule, all that is needed is to simply save the hash to verify what lies off-line.
- Save only the data required for the smart contract logic
6. Linking the blockchain to the real world
The blockchain itself transfers coins / tokens without problems, but how to transfer what is bought for them? Even if it is a file, how to ensure confirmation of its transfer without a third party? The short answer is: it’s not very easy, because we assume that both sides want to deceive each other and will be required to do a lot of checks, encryption and decryption, and if there is a dispute, you can’t do without off-line calculations or an arbitrator. As you know, for a physical product or service, everything is complicated by the fact that someone has to enter information that, roughly speaking, the product has been received. This someone can not be an interested person, then this is a third party, which we again have to trust. Then our blockchain solution has a weak place in the form of this arbiter, and since we trust him, why not trust everything else, let's say host the usual base and make payments. Before you do something you need to clearly answer this question. That is, for example, the meaning of the token, which you offer to exchange for a discount in an offline store, seems to us questionable
What to do?
Clearly answer yourself, what is not suitable centralized logic. If there is no answer, refuse the blockchain.
7. No insurance against user error
If you mistakenly sent money in the bank to the wrong place or your account was hacked, then you have the option to write in support, there is time to cancel or roll back the transaction. In smart contracts, you will not be able to manually do what is not provided by the code. Again we are faced with the need to introduce an arbitrator, who is granted privileges comparable to the centralization of the entire decision.
What to do?
If necessary, the introduction of an artificial delay in the transfer of funds in a smart contract
8. Long transaction time
If you have a dynamic system with constantly rewriting states and logic based on them, then you probably will not be satisfied with the waiting time, since at least in Ethereum, a normal transaction confirmation time can be considered as half a minute, and if not to go broke for gas, it is usually longer. Even if the account does not go for seconds, consider the possibility of delaying the transaction for an indefinite time and laying down sufficient intervals. So while games like poker are either not possible on pure Ethereum smart contracts, or are non-trivial and require an emphasis on off-line logic.
What to do?
- If you are planning a very frequent appeal to the blockchain, you should look not toward Ethereum, or maybe not toward the blockchain at all.
- If possible, collect several transactions into one, performing part of the logic of the off-line
- In extreme cases, you can increase the price for gas as needed.
- If the transaction does not go through for a long time, you can indicate the increased price and send it again (the transaction should remain unchanged, including nonce). More expensive will replace cheaper
9. Bypassing censorship is not perfect.
If you want to oppose the government or something like that with the help of the blockchain, be aware that the web service is still a centralized thing, even though it is based on the blockchain. That is, the domain name or ip can still be easily blocked and users will need to know the address of the mirror. Advantages - you don’t need to make backups of the database and knowing the address on the Ethereum network, you can always access less user-friendly means (Mist, MyEtherWallet, etherscan, etc.) But you can’t say that the problem of censorship is completely solved.
What to do?
Resistance to blocking is a bonus, but you should not base it on the decision to use a blockchain or not
If not Ethereum, then who?
Many who. Other blockchain and non-blockchain solutions may sacrifice either decentralization, or openness, or accessibility for an unlimited number of participants, in exchange for increased transaction speed, no privacy issues, etc. These are EOS, solutions for Hyberledger, Exonum, Hashgraph, Corda and more. But there is such an important factor as the name of the hearing. This is a large user base, and a large database of applications, information and development tools, tested. And this can be written in pluses to Ethereum. And let's see what Casper and Sharding will bring.
Is it all bad?
The most important issue going through all these points is the awareness of the choice of the blockchain. It is important that the technology solves the problem, adding a blockchain to an already solved task probably will not make the solution more effective.
For example, if you do not know who and you want to run a casino, then you have a problem to earn a reputation, show honesty and attract some kind of user base. By offering a solution on Ethereum, you can at least theoretically guarantee users a transparent job (although few people will actually audit your smart contract before the game). And attract people with extra cryptocurrency on the account and not enough opportunities to use it. We can say that the goal is achieved.
And if you want to add the blockchain to the messenger, then most likely not only do not solve the problems (and what they can be? - censorship and privacy come to mind), but also add new ones.
Finding more correct applications is probably a matter for the future, when the user base grows and it will be easier to buy cryptocurrency than now. But in general, you can look in the direction of such applications:
- Bureaucratic and long processes: translations abroad, paperwork
- Processes based on trust in the platform: funds, casinos
- Data used in different areas or unrelated companies: tour operators, credit history, black lists
- Control of unreliable processes: voting, fundraising
Affiliation of a task to one of the points does not mean that the blockchain will fit perfectly. Always see what other, more optimized technologies offer. That is, the line of thought should be “how to solve this problem,” and not “where to screw the blockchain.”
Diving into Ethereum development:
Part 1: introduction
Part 2: Web3.js and gas
Part 3: user application
Part 4: deploy and debugging in truffle, ganache, infura
Part 5: Oraclize