EOS’s soon to be launched mainnet is stirring up a lot of talk this recent month. As with many other coins this platform is supposed to be the next “Ethereum Killer”. It can be argued that any other blockchain will have a lot of trouble getting to the stage Ethereum is at currently in a short time frame because of the large developer base, tools and dApps that exist already. Either way though, EOS has a few interesting properties that would raise any developer’s eyebrows after using Ethereum for awhile.
EOS’s main advantages are fundamental to value proposition: zero fees for users, high initial TPS, and more safety features for users. All of these features are meant to make the system a more user friendly experience but at the cost of extensive decentralization and purity that a system like Ethereum has.
In this article I’m going to focus on how with current Ethereum tools the cost of transactions can be pushed back from the user to the provider. dApp developers can pay for gas, retry transactions that need a higher gas price, or any UX problem that is involved with performing transactions. All with users being able to interact with their favorite dApps with no Ethereum in their wallets and instead they’re just signing blobs of data.
Ethereum like almost all blockchains work on a public/private key system. Each user has an address that is the equivalent to your public key where ether and tokens can be sent or used for assigning rights in a smart contract. The users private key is what is traditionally stored in a user’s MetaMask, Ledger, Trezor or UTC file. This private key allows you to sign messages or send transactions on the Ethereum network.
When you send a transaction on the Ethereum network you’re signing an action to take place and be published on the network all in one. You then get charged the cost of the gas to perform whatever transactions you’re asking the network to perform.
This is where it starts to get strange for regular users: they’re not used to paying money to like a photo on instagram, publish a blog post or do any simple interaction in general on a platform.
dApps though could take on paying the gas prices for their users if they wanted while still giving all the benefits of the Ethereum blockchain’s security and allowing only discrete actions to be performed.
If this approach is to be taken dApps will have to conform by adding new functionality and intentionally doing this system from the start.
Below is an example John Backus of Bloom posted showing two example contract functions to accept a friend request in a fake smart contract based social network.
Source:
https://twitter.com/backus/status/981607967001739264
- backus
The first function would allow users to accept a friend request through an ethereum transaction where they pay the gas and all of the actions occur that are necessary. This is the standard request that currently exists for almost every function in Ethereum dApps today.
In the second function only the owner of the smart contract, the social network operator, can send a transaction to the contract that has a signed blob of data that must match the “Accept Friend” action, the address of the acceptor and the friend’s address they’re accepting. Limiting the scope of what an action blob can do and therefore contractually only allowing the user to choose the scope of an action.
This function then recovers the users address and message that was signed. Only addresses that match the acceptor address and have the specific properties also sent will be allowed to pass forward.
Note: In this example the recoverSigner function doesn’t exist in Solidity but you can use Open Zeppelin’s canonical library if you wish to have a similar function in your contract. You can find that here.
In this second scenario a user would sign a blob of data with their private key in MetaMask like shown on the left. This blob of data outlines a scope that user is allowing the smart contract to submit. When they click sign they are not charged any Ether because they’re just signing a message with their private key locally.
This signature would then need to be transported to the social network operator through either a standard API or potentially a decentralized system like Swarm or Whisper when they are more stable systems.
Once it reaches the social network operator they can handle submitting the TX to the system and any errors that are involved with that. Also therefore moving the cost of the transaction from the user to the dApp operator.
If the dApp is created properly there shouldn’t be any. Only the dApp owner can submit transactions that have an extremely limited scope or the user can submit them himself if the dApp owner fails to do so. Even if a snooper saw the signature they wouldn’t be able to do anything with it as they can not submit it to the application and even if they could submit the transaction (say the dApp didn’t have the onlyOwner modifier on the acceptFriendRequestFor function) they would only be able to do the strict request the user allowed.
Frictionless usability of the blockchain is a goal that all developers should strive for. Ethereum inherently puts up roadblocks and pattern changes to using applications that aren’t standard. Paying for interactions with an application, having to do an outside confirmation for each interaction and setting up an initial wallet without standard recovery methods are strange concepts to users. These can all be abstracted away with the right design patterns though. Through this abstraction usability can be increased exponentially. In the next part of this series I will be talking about how smart contracts can make safer, easier to use wallets with simple design principles.
About the Author: Petros is a Blockchain Engineer at a growing ICO launching company Block 16. We are a full service blockchain agency that does crypto-economics, network syndication, marketing services and blockchain development. If you would like to reach out to me send an email to [email protected].
