Ethereum, miracle child of a blockchain, and its Ethereum Virtual Machine (EVM), is one of the prominent examples of blockchain use. Many ICOs have built their businesses on smart contract, one of which is DApps or decentralized application. Now we discuss: is Ethereum really decentralized? Are there different or “better” ways of writing blockchain applications?
With Bitcoin’s basic scripting language, users are able to create applications that perform some tasks on an automated basis. These applications run mostly on private servers and are managed by centralized entities. These are similar to NEM, a completely new blockchain, written from scratch and with much broader and easier-to-access functions than Bitcoin.
The main ammunition of people attacking NEM (the second most popular platform to create ICO on) is its lack of decentralized smart contracts. But is Ethereum really a decentralized platform as it advertises to be? Will it be worth the use to gain a glimpse of decentralization when trading for the rigidity and security of your application?
To create a contract on NEM, you need to relate to one or more of the API requests and group them in an offchain application. Technically, it is difficult to confirm if an open source code on the NEM platform is really the code that is running on the entity’s server. But does that mean it is less decentralized than Ethereum contracts?
The first counterargument in decentralization’s defense is of the compilation of Ethereum’s source code. Currently, most applications on the EVM is the solidity compiled byte code, with minority of serpent compiled code. Let’s take the example of the simple HelloWorld contract. Every time we want to check if we can trust a contract, we as users should take the open source code, compile it in exact compiler that was originally used, and then check if the bytecode we get from this operation equals the bytecode from the uploaded contract.
Bytecode:
However, compiling and checking the bytecode of every contract we use isn’t the biggest problem. Currently, to make solidity contracts more robust and “upgradeable,” solidity developers use a special contract called Ownable.sol which allows the owner of the contract to modify some variables, kill the contract, or change the owner. It is very popular for contracts and is used by main contracts on Ethereum, making them centralized and much more robust at the same time. It allows the owner of the contract to write into external data storage without changing the contract logic. Also, most modern contracts are upgradeable through versioning system and/or detaching logic, which can be updateable from immutable data storage.
Using these techniques is considered good practice when writing a solidity code for Ethereum VM. But is it much different from scripting languages (historical Bitcoin and upcoming NEM) that are more contract-centralized but more secure on the code? At the end of the day, modern solidity contracts are decentralized only in the sense of storing timestamped data on the blockchain, while well-architected contracts are editable by owners. But if it isn’t different than non-turing complete blockchains, why learn another complicated language to access the blockchain data when you can simply use RestfulAPI-based NEM blockchain?
Bartłomiej Tony Sanak
