Insights into Ethereum Smart Contract Development

Many of you have probably questioned the usefulness of blockchain in general and Ethereum in particular. Some of you may have gone further in your curiosity and came across numerous fancy characteristics, such as decentralization, transparency, trust without intermediaries, and hack resistance. That’s remarkable, isn’t it? It sure is, but…

In its current state, blockchain is a perfect match for fulfilling a narrow range of tasks, unless you consider “adding some nanotechnologies for a wow effect” to be a task – in fact, you can adjust nearly anything to align with this objective. Of course, something needs to be done for a start, with various experiments helping understand the potential and showing where the demand can be, where an unexpected dead end is, and where the drawbacks turn out not as critical as predicted. You do need to know about the boundaries, though, in order to make an informed decision whether it’s reasonable to try and step over them in a particular scenario.

By the way, Ethereum isn’t the only and the best-ever option. Perhaps, blockchain is the right instrument to achieve your goal, although a different type of blockchain. Yet, we will imply “Ethereum” as we further mention “blockchain” in this article.

Let’s try to overview the features of blockchain and smart contracts that make the process of solving ostensibly promising tasks ineffective or impossible altogether. I’d like to point out from the get-go that the characteristics below are generalized, so there may still be fairly viable solutions for specific use cases. Therefore, you should treat this list as a collection of Ethereum’s weaknesses to consider before you get started with your project.

1. High entry barriers

If your audience comprises regular users rather than blockchain enthusiasts, then very few of them will ever bother giving your solution a shot. Just think about it – they won’t only have to install MetaMask or Mist with a node, but they’ll also need to buy some Ether, which is a nontrivial process for beginners. Therefore, if you seek to cover a maximum audience, then Ethereum isn’t the right pick so far. For instance, it’s probably a bad idea to create an online store based on smart contracts only.

What to do?

• Offer benefits that outscore the inconveniences.
• Target an audience with some expertise in the subject.
• It would make sense to obfuscate the blockchain logic from the user by moving it to the backend.

2. Decentralized centralization

No matter how you slice it, blockchain is great because it works even if participants don’t trust each other at all. However, this hallmark only holds true as long as the user is the sole owner of their private key. That’s the main prerequisite for signing transactions and doing other things from their address. What happens if the blockchain logic is at the backend? The keys are used in a centralized way, and there is no mechanism to avoid transactions that aren’t sanctioned by the user. Therefore, all that’s left to do is hope that the server is secure enough and properly maintained.

What to do?

• Understand whether you need transparency and immutability or the option of manipulating cryptocurrency. If you don’t, it’s more cost-efficient and convenient to use a regular database.
• Elaborate your operational mechanisms so that technological guarantees are in place.

3. All the data is public

Regardless of how a smart contract is written, an interested party can retrieve the value of any data field in it if they want to. The same applies to the transactions history. Consequently, if you log and retain any personally identifiable information about users, such as their email addresses and names, then everything these users do is publicly accessible. You may therefore have to engage some type of encryption on top of that. If so, the keys for it must be stored on the recipient’s end, which means the user, again, has to trust a third party with their personal data. Using commonplace private storage to keep more or less sensitive information might be a better idea. If you are going to make blockchain-based contracts, then you may lose more than you gain.

What to do?

• Understand whether your smart contract logic requires users’ personal data. If it does, consider leveraging hashes instead of the data proper.

4. Blockchain isn’t a supercomputer

Some people may get the impression that miners utilize enormous processing power for benign computation, but that’s a misconception. Let me get this straight: Ethereum’s productivity resembles the productivity of an embedded system as it involves limited resources, limited amount of memory, and limited size of “firmware” (contract byte code). Therefore, a maximum of non-critical calculations should be moved off-chain. This is why performing complex data analysis in smart contracts or things like encryption is hardly feasible.

What to do?

• Do not use blockchain for calculations of any sort.
• If you need to conduct blockchain-related calculations, consider leveraging the Oraclize’s Computation feature

5. Blockchain isn’t a universal storage

Some people believe blockchain can be used to store information or documents. The caveats are apparent in this regard: first of all, storing data this way is expensive; secondly, blockchain doesn’t get along with things like search – you either need to have the key-value mapping in place, which will add some extra cost to every entry, or you have to look for information of interest manually. Furthermore, there is no permissions management. So, replacing a conventional database with blockchain doesn’t make much sense unless you know exactly why you need it. When it comes to storing specific files, keep the public accessibility aspect in mind: if you store, say, an IPFS link, everybody will see it and can download everything you keep there. Long story short, think twice if you are up to storing personal photos on blockchain.

What to do?

• You’re better off simply storing a hash for verifying everything stored off-chain.
• Only store the data required for the smart contract’s working logic.

6. Tying blockchain to real world

Blockchain per se can easily send coins/tokens, but how to send the stuff you buy for them? Even if it’s a file, how do you verify the fact of sending it without involving a third party? Here’s a quick answer: it’s not too easy, because we assume that both parties want to deceive each other, and so we need a bunch of verifications as well as instances of encryption and decryption. In case there’s a dispute, you simply cannot do without off-chain computation or a referee.

It’s clear that the whole process is going to be yet more complicated for physical goods or services, because someone needs to input the information that, roughly speaking, the goods have been received. This person must not be an interested party, which means he or she is a third party whom we are supposed to trust. In this case, our blockchain solution has a weak link in the form of this referee. Also, given that we presumably trust that person, why not trust him or her with everything else, for example, with hosting a regular database and making payments? This is a fundamental question you should ask yourself before starting your blockchain initiative. For instance, I don’t really understand what’s the use of a token that you offer to exchange for a discount in an offline store.

What to do?

• Give yourself a clear answer why centralized logic isn’t suitable. If you can’t, then abandon your blockchain idea.

7. There’s always a chance of human error

If you have transferred money to the wrong person by mistake or your bank account has been hacked, you can submit a tech support ticket and there is some time to cancel or rollback the transaction. With smart contracts, you can’t manually do things that aren’t covered by the code. This, again, brings us to the necessity of engaging a referee who will have vast privileges that cause the whole solution to become nearly centralized.

What to do?

• Implement an artificial delay of fund transfers in the smart contract where appropriate.

8. Transactions take time

If you have a dynamic system featuring permanently changing statuses and logic based on them, then the wait time will most likely dissatisfy you. In Ethereum, for instance, the normal transaction verification time is half a minute or even more than that. Even if a few extra seconds aren’t an issue for your solution, you should still take the possibility of indefinite transaction timeouts into consideration and define the sufficient time intervals. Therefore, games like poker are either completely impossible to create on the Ethereum smart contract basis so far, or they can be quite primitive and require an emphasis on off-chain logic.

What to do?

• If you intend to query the blockchain frequently, Ethereum might not be the perfect match, and perhaps you shouldn’t restrict your outlook to blockchain alone.
• If possible, combine several transactions into one, executing part of the logic off-chain.
• At the worst, you can raise the gas price (fee for executing an operation) where appropriate.
• If a transaction takes too long to complete, you can indicate a higher price and resubmit it (the transaction must remain immutable, including the nonce value). This way, the higher price will replace the lower one.

9. Censorship evasion isn’t perfect so far

If you are up to using blockchain to resist the government or something like that, keep in mind that a web service is still a centralized entity, even if it’s based on blockchain. In other words, a domain name or IP address is still easy to block and the users will have to know the mirror address or find a VPN service. The benefit is that you don’t have to make database backups, and by knowing the address in the Ethereum network you can always gain access by means of less user-friendly techniques, such as Mist, MyEtherWallet, Etherscan, etc. However, censorship continues to be an issue.

What to do?

• Resilience to blocking is definitely a benefit, but you shouldn’t make the decision to use blockchain based on this fact alone.

What are the alternatives?

There are plenty of them. Other blockchain and non-blockchain solutions can sacrifice their decentralization, openness, or unlimited user audience in exchange for higher transaction speed, reliable privacy protection, etc. The examples include EOS, solutions based on Hyperledger, Exonum, Hashgraph, Corda, and many others. A popular brand name is still an important factor, though. It implies that there is a large user base, plenty of apps, data management and development instruments, as well as scrupulous testing mechanisms. All of these are on the plus side of Ethereum. Time will tell whether things pan out for Casper and Sharding.

Is it that bad?

The fundamental issue permeating all of the above points is the conscious choice of nothing but blockchain. The technology is supposed to address a problem. Integrating blockchain into a task that’s already solved isn’t likely to make the solution any more effective. For example, if you are a new player in the gambling business and want to launch a casino, then your main concern is to get yourself a reputation, demonstrate uprightness and attract a user base. By offering an Ethereum-based solution you can at least theoretically guarantee transparency to customers, although few people will ever audit your smart contract before they start playing. This way, you will also attract people with spare cryptocurrency assets on their hands and plenty of capabilities to use it. In a way, the goal is achieved.

On the other hand, if you intend to add blockchain to a messenger’s architecture, then you will probably fail to solve any problems, such as censorship and privacy risks. Instead, you will get new issues.

Finding better use cases might be a matter of the near future, when the user base grows and it becomes easier to purchase cryptocurrency than it is now. Generally, though, it makes sense to consider the following application domains:

1. Bureaucratic and time-consuming processes, such as money transfers abroad and cumbersome paperwork.
2. Processes based on trust for the platform, including charity funds and casinos.
3. Management of data used in various domains or unrelated companies: tour operators, loan history, and all kinds of blacklists.
4. Controlling intrinsically untrustworthy processes, such as voting and fundraising.

The fact that a task falls into one of these categories doesn’t necessarily mean that blockchain will fit into it flawlessly. You should always stay on top of what other, more optimized technologies have to offer. Your flow of thoughts should focus on addressing a particular problem rather than embedding blockchain into your activity no matter what.

About the author: The author, David Balaban, is a computer security researcher with over 15 years of experience in malware analysis and antivirus software evaluation. 

Disclaimer: The views expressed in the article are solely that of the author and do not represent those of, nor should they be attributed to CCN.

Follow us on Telegram or subscribe to our newsletter here.
• Join CCN’s crypto community for $9.99 per month, click here.
• Want exclusive analysis and crypto insights from Hacked.com? Click here.
• Open Positions at CCN: Full Time and Part Time Journalists Wanted.
Advertisement