Advertisement
Guest User

Untitled

a guest
Mar 26th, 2017
1,317
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 15.93 KB | None | 0 0
  1. Ethereum
  2. Introduction
  3. Ethereum is another distributed blockchain network. However, it differs significantly from bitcoin. Whereas the bitcoin blockchain can only be used to track the ownership of bitcoins, the Ethereum blockchain can store and execute programs. The programs themselves and a history of every state alteration are stored as transactions on the blockchain.
  4. Ethereum still has the mining process, like bitcoin, which confirms transactions and secures the system through the Keccak-256 hashing algorithm. [ref]. Miners are rewarded for processing transactions in Ether which is the token, or cryptocurrency, which fuels the network.
  5. Programs living on the blockchain are referred to as smart contracts. The etymology of the phrase might have origins in the autonomous ability of contract code to facilitate exchanges of value. Ethereum allows people to safely interact trustlessly by entering into neutrally enforceable agreements in a completely peer-to-peer fashion. [ref] [gitbooks frontier guide] Once mined, contracts on the blockchain are immutable and immortal, and their functions are called whenever specific conditions are met. Contracts can be written in Solidity (similar to JavaScript), Serpent and Viper (Python derivatives) and LLL. [ref] [Wikipedia ethereum].
  6. While many blockchains, including bitcoin, can process code, most are lacking in a robust scripting language for developing applications. Ethereum was initially described in a white paper by former bitcoin programmer Vitalik Buterin, who proposed the development of the platform after failing to convince bitcoin core developers to implement such a feature. [ref] [Wikipedia ethereum]. Before Ethereum, blockchains were specialised for specific applications. One example is Namecoin; a key/value pair registration and transfer system based on blockchain technology, with applications including DNS and identities. Ethereum’s core idea is to generalise to be broadly applicable; hence the support of the native programming language.
  7. Why use Ethereum?
  8. The primary benefit that Ethereum DApps offer is decentralisation. DApps are comprised of contracts that exist on the blockchain. Therefore, no single individual or central entity controls them. Participants in such a system can be confident that the rules they expect to be enforced, will be, in a perfectly deterministic fashion. There is no danger of corruption, bribery, nepotism, political bias, exclusion, arbitrary exceptions, human oversight or absence of staff. This is discussed further in the Comparison with Traditional Trusted Third-Party Models of Financial Transfer.
  9. Ethereum as a platform provides a set of integral features which are very useful to developers:
  10. - User authentication via integration of cryptographic signatures
  11. - Fully customisable payment logic; payment systems can be created easily without any reliance on third parties (e.g. card processors, PayPal)
  12. - 100% DDOS resistant up-time, guaranteed by being a fully decentralised blockchain-based platform
  13. - In-built storage: no need to set up secure databases as Ethereum blockchain can provide
  14. - Ultimate interoperability: everything in the Ethereum ecosystem can trivially interact with everything else
  15. - Server free: there is no need to set up or maintain servers with DApps
  16. On a more abstract level, Ethereum can facilitate smart organisation. In any group or organisation, rules must be decided upon so that participants might operate together. Ethereum provides a platform on which rules can be defined and enforced. To give a concrete example, a film-making collective might prevent outsiders from using their equipment, requiring their DApp’s approval of a user’s access code.
  17. Comparison with Traditional Trusted Third-Party Models of Financial Transfer
  18. Using a decentralised system for facilitating transfer of wealth, offers several benefits over using the familiar trusted third-party processor model. With a trusted third-party (e.g. bank, card payment processor, PayPal etc.) one relies entirely upon said authority to act fairly and abide by rules and regulations. But considering the influence that these organisations have over society and even over government policy, it could be argued that it would be unwise to place too much trust in them. For instance, during the 2008 Financial Crisis, it was found that certain financial institutions took part in problematic practices, requiring government bailouts at the taxpayers’ expense. A decentralised financial system would eliminate any moral hazard and potential for corruption, as all code on the Ethereum blockchain is open source and immutable. [ref] [5] [interim]
  19. Any centralised database or similar solution, as kept by traditional financial institutions, becomes an attractive target for hacks. To add to this, once personal information has been submitted to a third-party, it can be near impossible for users to retain control of this information. In many instances, it is required to hand over private personal information to central authorities. As privacy has become more and more of a concern in recent years, a system using blockchain technology offers a great advantage in that all activity is pseudonymous. Ethereum uses alphanumeric strings for personal account addresses (where a user’s “Ether” cryptocurrency is stored) and for smart contracts deployed on the network. A user can generate multiple addresses to obscure their identity. Users are not coerced into submitting personal information.
  20. Trusted third-parties have been known to charge extortionate fees for transfers and other services. In the case of a decentralised system, with perfect information i.e. total network processing power, number of transactions occurring etc. available to all actors, it is in theory possible to determine a fair rate (to be paid to the miner) for any given transaction. Furthermore, cryptocurrencies ignore national borders and currency exchange altogether.
  21. On top of this, the Ethereum network is immutable and accessible to any device that can connect to a node. The possibility that the system will be inaccessible at any time is slim, as thousands of nodes would have to disconnect simultaneously. The JavaScript Web3 API for Ethereum facilitates this usability. With it, the Ethereum “mainnet” network can be accessed from anywhere. Users are not required to run a network node, but can simply connect to one. Using their private key, they can authenticate themselves and make transactions and execute blockchain code via API method calls.
  22. However, this is not to say that there are no issues or associated risks. When allowed complete control over one’s finances, users are presented with numerous opportunities to perform erroneous or unwise actions. For instance, if a user makes a transaction sending money to an incorrect address, there is no central authority to contact to mediate and resolve the issue. The level of control given to the user is a double-edged sword; on the one hand, the user can perform actions with complete freedom, on the other, there are no in-built controls, checks or balances in place to prevent users from causing trouble to themselves.
  23. Ether (the cryptocurrency used in the system) is difficult to exchange for anything of real value. If one possessed Ether and wished to make a purchase, one would have to convert the Ether into a trusted fiat currency. To do so, one would have to utilise an exchange service of some form, typically requiring submission of private personal information, thus eliminating one of the advantages of using cryptocurrency (pseudonymity).
  24. While Ethereum does allow people to interact trustlessly, Ethereum can only enforce rules within its own digital limits. Ethereum does not remove the need for an external authority for adjudication of disputes outside its realm. For instance, if the counterparty in a digital contract decides to recoup a payment via physical extortion, the Ethereum smart contract cannot possibly cover this scenario. What Ethereum does do is push the boundary on what the digital realm can cover.
  25. [ref] [ethereum gitbooks intro page]
  26.  
  27.  
  28. Under the hood
  29. Bitcoin operates using public key cryptography. Each user has a wallet which is a collection of public and private keys. Bitcoins are transferred between addresses which are essentially shorthand for the private keys. The example below illustrates the process that takes place when a user makes a transaction.
  30. - Alice sends 1 Bitcoin to Bob
  31. o Alice makes the transaction
  32. o 1 btc will be deducted from her specified public address
  33. o 1 btc will be added to one of Bob’s public addresses (specified by Alice)
  34. o The transaction is signed with Alice’s private key before being relayed to the network
  35. o Nodes verify the validity of the transaction, checking the signature against her pubic key
  36. o Invalid transactions (i.e. those not originating from Alice) are rejected by the nodes and are not relayed further
  37. o Valid transactions are relayed to other nodes, eventually finding their way into the blockchain
  38. Ethereum has two types of accounts (this term can be used interchangeably with Bticoin’s addresses). [ref] [ethereum gitbooks io frontier guide]
  39. - Normal or externally controlled accounts
  40. o Identical to bitcoin accounts
  41. - Contracts
  42. Transactions can be fired from both types of accounts, though contracts only fire transactions in response to other transactions that they have received. Therefore, all action on the Ethereum block chain is set in motion by transactions fired from externally-controlled accounts.
  43. [ref] https://chrispacia.wordpress.com/2013/09/07/bitcoin-cryptography-digital-signatures-explained/
  44. [ref] https://github.com/ethereum/go-ethereum/wiki/Contracts-and-Transactions
  45. Under the hood: transactions
  46. An Ethereum transaction is any kind of computation which changes the state of the Ethereum Virtual Machine (EVM). In Bitcoin, every transaction boils down to sending x bitcoins from A to B. Ethereum also features these types of transactions; the sending of x ether from A to B. However, Ethereum contract function calls are also stored as transactions on the blockchain i.e. calling function F of contract C with arguments A. Simple getter functions do not change the state of the EVM and can return results without creating a transaction. This is achieved by chaining the .call(args) function to the end of myContract.myFunction i.e. var returnValue myContract.myFunction.call(myFunctionArgs) in web3.js. These calls are executed locally. No interaction with the blockchain takes place, bar the initial retrieval of the contract’s fields and functions (also read-only).
  47. To interact with a contact living on the blockchain, the Web3 JavaScript API requires the Application Binary Interface (ABI) and the contract’s address on the blockchain.
  48. The ABI effectively functions as an interface for the Web3 API. It defines how solidity contract code interacts with the EVM (the distributed singleton computer). In other words, it is required for the contract code to be known beforehand for the JS Web3 API to interact with it.
  49. - A Web3 object can be instantiated in the front-end JavaScript
  50. o var web3 = new Web3(new Web3.providers.HttpProvider(“http://localhost:8545”));
  51. o The above code snippet refers to an instantiation of a web3 object with the provider set to the local Ethereum node
  52. o I.e. the web3 object can interact with contracts residing on the network that the local node belongs to
  53. o In the context of this project, this refers to a local test network
  54.  Not the main network of Ethereum nodes
  55. The ABI is a JSON object which contains a description of the functions and events of a given contract. It is a description of the contract itself. The web3 object requires both the ABI and the contract’s address on the blockchain to interact with it.
  56. Web3 API:
  57. - var contractInstance = web3.eth.contract(abiArray).at([blockchainAddress])
  58. o contractInstance.myFunction.sendTransaction(args)
  59. o contractInstance.myFunction.call(args)
  60. sendTransaction is appended to the function call for functions which change system state. call is appended for functions which just retrieve state (read-only functions).
  61. The example above demonstrates how to instantiate contracts which have already been deployed on the blockchain.
  62. The example below demonstrates how to deploy new instances of contracts via the web3 API.
  63. Web3 API:
  64. -
  65. New contracts can be deployed via the Web3 API using the function call below:
  66. Web3 API:
  67. - Var contractInstance = myContract.new([contrstructorParam1] [,constructorParam2], {transactionObject})
  68. The newly deployed contract needs to be a transaction because it changes the state of the blockchain and EVM.
  69. A transaction is added to the blockchain via the web3 API call web3.eth.sendTransaction(transactionObject [, callback])
  70. The transactionObject itself takes the following parameters:
  71. - from: String - The address for the sending account. Uses the web3.eth.defaultAccount property, if not specified.
  72. - to: String - (optional) The destination address of the message, left undefined for a contract-creation transaction.
  73. - value: Number|String|BigNumber - (optional) The value transferred for the transaction in Wei, also the endowment if it's a contract-creation transaction.
  74. - gas: Number|String|BigNumber - (optional, default: To-Be-Determined) The amount of gas to use for the transaction (unused gas is refunded).
  75. - gasPrice: Number|String|BigNumber - (optional, default: To-Be-Determined) The price of gas for this transaction in wei, defaults to the mean network gas price.
  76. - data: String - (optional) Either a byte string containing the associated data of the message, or in the case of a contract-creation transaction, the initialisation code.
  77. - nonce: Number - (optional) Integer of a nonce. This allows to overwrite your own pending transactions that use the same nonce.
  78. [ref] [https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethsendtransaction]
  79. The callback function is an optional parameter that can be passed to the function in case an asynchronous request is required. In other words, if the call is being made from a device separate from the Ethereum node, the return values of the callback function will be returned asynchronously. The web3 API assumes that function calls are being made locally from an Ethereum node. Therefore, callback function must be passed for asynchronous front-end functionality i.e. device is connected to Ethereum node which makes web3 API calls (without asynchronicity, the front-end will be frozen until the transaction is mined).
  80. Callback functions take a form similar to the example below:
  81. Web3.eth.myContract.myFunction([myArgs], function(error, result){
  82. if(!error)
  83. console.log(result)
  84. else
  85. console.log(error);
  86. })
  87. In the above example, the callback function is the anonymous function taking parameters error and result.
  88. The first argument of the callback is reserved for an error object. If an error occurred, it will be returned by the first err argument.
  89. The second argument of the callback is reserved for any successful response data. If no error occurred, err will be set to null and any successful data will be returned in the second argument. With the callback function, the front-end is not kept waiting by the pending mining of any given transaction. In other words, the front-end is not frozen waiting on a return value from a transaction, which must be mined/processed. Other contract functions may be called via the front-end before a value is returned. The front-end is updated asynchronously as transactions are mined by the network.
  90. The sendTransaction function returns the 32 byte transaction hash as a hex string, once mined/processed. The transaction (change of network/EVM state) is permanently stored on the blockhain). The transaction hash is a reference to this state change.
  91. Gas
  92. Every EVM operation requires gas which is denominated in Ether. The sender of a transaction specifies a gasLimit as a parameter of the sendTransaction function. The gasLimit is the maximum amount of Ether that the sender is willing to pay to miners/processors for any given transaction e.g. contract deployment, contract function call etc.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement