![\"Ethereum\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/08\/eth_logo.png\")
<\/a><\/h1>\nThe Ethereum project was started around 2014 as a platform for smart contract development. It is built on blockchain technology, representing a distributed, secure-by-design database. This global infrastructure allows us to represent ownership and move property between network participants.<\/p>\n
Ethereum can be seen as a second generation blockchain platform, if we would count Bitcoin as the first. The biggest step forward was the introduction of smart contracts. Instead of having each transaction only carry a certain amount of “coins”, now you can also store code, which is supposed to interact with the data in the blockchain.<\/p>\n
Another improvement was a new proof-of-work concept. Bitcoin’s proof-of-work has the inherent problem that specialized hardware (so-called ASIC) is much better at mining than regular hardware. Thus, the amount of possible competitors for the generation of the next block decreased a lot over time, since often the power consumption costs were higher than the value gained through mining. In Ethereum, the proof-of-work was changed so that regular GPU’s are already indirectly optimized for this kind of task.<\/p>\n
Smart Contracts<\/h1>\n
Smart contracts allow us to exchange property, or anything of value in that matter, in a secure and conflict-free way without the need for a middle man. They not only define rules and penalties of an agreement like in a regular contract, but also enforce those obligations automatically. Smart contracts could be compared to a vending machine: You fulfill some requirement (e.g. putting a coin in the vending machine), and you automatically earn the expected results.<\/p>\n
In Ethereum, smart contracts received their own scripting language called Solidity, which targets the Ethereum Virtual Machine (EVM). With it we can develop similar to other programming languages, besides some smaller quirks due to the unique nature of a Blockchain.<\/p>\n
contract MyToken {\n \/* This creates an array with all balances *\/\n mapping (address => uint256) public balanceOf;\n\n \/* Initializes contract with initial supply tokens to the creator of the contract *\/\n function MyToken(uint256 initialSupply) {\n balanceOf[msg.sender] = initialSupply; \/\/ Give the creator all initial tokens\n }\n\n \/* Send coins *\/\n function transfer(address _to, uint256 _value) {\n if (balanceOf[msg.sender] < _value) throw; \/\/ Check if the sender has enough\n if (balanceOf[_to] + _value < balanceOf[_to]) throw; \/\/ Check for overflows\n balanceOf[msg.sender] -= _value; \/\/ Subtract from the sender\n balanceOf[_to] += _value; \/\/ Add the same to the recipient\n }\n}<\/pre>\nThe idea now is that every contract also has an address, similar to regular participants in the network. This means that they can be the recipient of a transaction, allowing the usual transfer of funds, and also of instructions, i.e. calls to the contract’s member functions, through our supplied code in the transaction.<\/p>\n
Since the data is stored in a tamper-free way, it can, for instance, be used for verification purposes. One could implement a smart contract imitating the traditional land register, without the need for additional notary services. Or a company could use this technology for its supply chain management, to prove the point of origin for each of their products.<\/p>\n
The possibilities are seemingly endless and it is obvious that many current systems could be improved with this kind of technology. However, there are, of course, also drawbacks. For one, the concept of “proof-of-work” to guarantee the integrity of the network requires a lot of computational power and therefore comes with a high power consumption. There are some new techniques in development (-> proof-of-stake) to remedy this issue, but currently it still has to be taken into account. Also, for some applications the openness of a Blockchain may be problematic. Nevertheless, we should keep in mind that blockchain technology in general is also just another tool among others in our software development toolbox, which may be good for certain applications, but has limitations regarding others.<\/p>\n
Structure of a Dapp<\/h1>\n
A decentralized app (or Dapp) is an application that makes use of Ethereum smart contracts in the background. Therefore each Dapp requires access to the Ethereum network somehow. Ethereum offers several, open-source clients, the most popular ones being:<\/p>\n
\n- Geth (Implementation in Go)<\/li>\n
- Eth (Implementation in C++)<\/li>\n
- Pyethapp (Implementation in Python)<\/li>\n<\/ul>\n
Through them we are able to read from or write to the blockchain. They all offer more or less the same functionality, however Ethereum didn’t want to limit themselves to one client only for security purposes. By default, those clients offer a console environment to pass commands. In the case of a Dapp, though, we need this interface in our (web) application. Therefore we can set the client to act as a so-called JSON-RPC endpoint to supply a JavaScript interface – called web3 – on an arbitrary port. In our application, we only need to load the web3 library, and connect it to the RPC endpoint. Now we are able to access all important features of the Ethereum client in our JavaScript application.<\/p>\n
MetaMask<\/h1>\n
The idea now is that every contract also has an address, similar to regular participants in the network. This means that they can be the recipient of a transaction, allowing the usual transfer of funds, and also of instructions, i.e. calls to the contract’s member functions, through our supplied code in the transaction.<\/p>\n
Since the data is stored in a tamper-free way, it can, for instance, be used for verification purposes. One could implement a smart contract imitating the traditional land register, without the need for additional notary services. Or a company could use this technology for its supply chain management, to prove the point of origin for each of their products.<\/p>\n
The possibilities are seemingly endless and it is obvious that many current systems could be improved with this kind of technology. However, there are, of course, also drawbacks. For one, the concept of “proof-of-work” to guarantee the integrity of the network requires a lot of computational power and therefore comes with a high power consumption. There are some new techniques in development (-> proof-of-stake) to remedy this issue, but currently it still has to be taken into account. Also, for some applications the openness of a Blockchain may be problematic. Nevertheless, we should keep in mind that blockchain technology in general is also just another tool among others in our software development toolbox, which may be good for certain applications, but has limitations regarding others.<\/p>\n
Structure of a Dapp<\/h1>\n
A decentralized app (or Dapp) is an application that makes use of Ethereum smart contracts in the background. Therefore each Dapp requires access to the Ethereum network somehow. Ethereum offers several, open-source clients, the most popular ones being:<\/p>\n
Through them we are able to read from or write to the blockchain. They all offer more or less the same functionality, however Ethereum didn’t want to limit themselves to one client only for security purposes. By default, those clients offer a console environment to pass commands. In the case of a Dapp, though, we need this interface in our (web) application. Therefore we can set the client to act as a so-called JSON-RPC endpoint to supply a JavaScript interface – called web3 – on an arbitrary port. In our application, we only need to load the web3 library, and connect it to the RPC endpoint. Now we are able to access all important features of the Ethereum client in our JavaScript application.<\/p>\n