Smart-contracts: Ethereum vs. Obyte

Smart-contracts have become synonymous with Solidity scripts on Ethereum and they can be used to create many things: multi-signature wallets, fungible and non-fungible tokens, payments with the escrow and so on. In most cases, you don’t need to decentralize all user interactions, so smart-contracts should do as less as possible. Some people have found out about that the hard way when their smart-contracts cannot be executed anymore because of block gas limit and unbounded loops.

There are endless ways how the same functionality can be written differently in Solidity, which means that these smart-contracts are usually not readable for regular users (even after the source code has been verified) and each implementation of the same functionality can have different bugs because a developer might have forgotten to restrict access to something that should have been limited by default (Parity hack). It’s good to see standardization of basic functionalities (ERC20, ERC721, SafeMath) on Solidity code, but it’s usually too late if your broken code is already up there and you didn’t think about how to replace the broken parts of you smart-contract. Also, ERC20 only defines required functions for the token, but every developer can still write their own implementation — so not all ERC20 tokens are the same. The possibility to implement functions to replace some parts of your smart-contract could also mean that the same ERC20 standard token can tomorrow have different spending rules or even paused by the developer.

Smart-contracts on Obyte are readable for developers and users.

Features built-into Obyte platform

Fortunately, this is not the only way to have smart-contracts. Obyte is an open cryptocurrency platform built using DAG (directed acyclic graph) and it has human readable smart-contracts, which have a set of conditions that need to be true to transfer funds out of them. Obyte platform also has multi-signature wallets, user-created tokens, payments with the escrow and many other usual smart-contract use cases already built-into the platform. It is still possible for a developer to miss some conditions in smart-contracts that can leave bugs in those deployed smart-contracts, but it’s more difficult to make other mistakes because the smart-contract language is declarative on Obyte.

Cost predictability

On Ethereum, in most cases, the developer would have to pay only for deploying the smart-contract, users pay will pay for all other interactions. In reality, the business is also another counterpart for the users and needs to execute some functions too. Since every operation in Ethereum smart-contract costs gas, if a developer added a function that needs to go through the growing list of user addresses, the cost of executing that function will also go up as the list gets longer. Ethereum throughput is limited with block size the same way like Bitcoin, so when there are more users, the fees go up too.

On Obyte, every payment and every data posted by oracles costs as much as it takes space in public database, which means that the fees are predictable for the developers and businesses can estimate how many Obyte Bytes (native coin) they need to acquire for the next year or more. This is possible because DAG architecture doesn’t have block size limit and no block time limit.

Last, but not least, Solidity is a Javascript-like language, but it’s not Javascript, which means it has a steeper learning curve than other existing languages. This means more costs for developing and more bugs. Obyte is written on well-known NodeJS and Obyte smart-contracts are just nested conditions in JSON code.

Smart-contracts: Ethereum vs. Obyte was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.