Ethereum Developer Meetup of the Century:
Vitalik Buterin, Joseph Poon, Jun Hasegawa
Some Background on Ethereum (Quoting the White Paper)
In short, Ethereum: "provides a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions...Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform." Three things Ethereum offers that Bitcoin does not include: "Turing-completeness, value-awareness, blockchain-awareness and state."
Turing-completeness: at its core, the bitcoin scripting language does not allow for loops. While some may argue this as a security measure, it limits developers and leads to hackish and inefficient solutions to certain problems.
Value-awareness: bitcoin transactions must be spent in an all-or-nothing fashion. Thus, if I received 3 BTC from Alice and I want to send 2 BTC to Bob, I must include all 3 BTC, sending 2 BTC to Bob and 1 BTC back to myself.
Blockchain-awareness:bitcoin transactions are not aware of the state of the blockchain. Thus, it cannot react to nonce or meta-data, an awareness that may limit potential capabilities such as randomness.
State: all bitcoin transactions are either spent or unspent. There is no way to form a multi-stage contract/transaction.
Ethereum Accounts: there are two types of Ethereum accounts, externally owned and contract. Externally owned have no code, are controlled by private keys, and are able to send messages. Contract accounts are built on code and respond to messages; they are not fulfilled, but "rather, they are more like "autonomous agents" that live inside of the Ethereum execution environment, always executing a specific piece of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables."
Ethereum Transactions: "The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account." These require the typical parts of a blockchain tx (recipient address, signature, ether), but also have optional data that may be read by a contract, and gas that acts as a safety valve against infinite loops in poorly written or malicious contracts.
Ethereum Messages: just like transactions, but these are sent between contracts. Messages "are virtual objects that are never serialized and exist only in the Ethereum execution environment."
EVM: EVM stands for Ethereum Virtual Machine. This is where the code is executed... it is not executed on the blockchain.
Ethereum Blockchain: Very similar to Bitcoin except that "unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state."
HOW is CODE EXECUTED? "the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B."
Types of Applications:
- Financial: ex) currency
- Semi-financial : ex) self-enforcing bounties
- Non-financial: ex) voting
Token Systems on Ethereum: " just a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (ii) the transaction is approved by A. All that it takes to implement a token system is to implement this logic into a contract."
Ever wondered what "uncles" are? Well, me too. According to the White Paper, in quick confirmation consensus protocols, there is a high chance miner A mines a block and miner B mines a block before knowing miner A mined a block. Thus, miner B would mine an unused block, or a stale block. With large mining pools, this is an issue, so Ethereum works to solve this: "as described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the "longest"; that is to say, not just the parent and further ancestors of a block, but also the stale descendants of the block's ancestor (in Ethereum jargon, "uncles") are added to the calculation of which block has the largest total proof of work backing it." These uncles get a smaller, but respectable award for their work.
Turning Completeness, a thing of beauty: Turning-completeness is managed by a) gas limits so contracts will have a saftey valve, b) message limits so attackers cannot send huge messages to halt processes and c) the revert function that reverts the effects of a half executed code. Thus, the White Paper concludes that "Turing-completeness is surprisingly easy to manage, and the lack of Turing-completeness is equally surprisingly difficult to manage unless the exact same controls are in place - but in that case why not just let the protocol be Turing-complete?"
Scaling Ethereum
Ethereum, like Bitcoin, is running into scaling issues. During ICO's the network is bogged down and gas fees(transaction fees) rise sky high. There are four solutions to the issue (won't go into detail here):
- Sharding: https://github.com/ethereum/wiki/wiki/Sharding-FAQ
- Raiden Network: https://raiden.network/
- Truebit: https://www.coindesk.com/inside-truebit-ethereum-scalability-effort/
- Plasma: https://plasma.io/plasma.pdf
Also, Ethereum is on the path to switch from POW to POS, and will use their own POS consensus protocol nicknamed Casper. The network change that will take place is being called Metropolis, a series of two hardforks, the first called Byzantium and the second Constantinople.
OmiseGo: Jun Hasegawa
Who is Jun Hasegawa?
Jun Hasegawa is the creator of Omise. Based out of South East Asia, Omise is making its way into cryptocurrency with its produce OmiseGo.
His talk:
Jun discussed, at length, the future path of OMG. He continuously hinted at a breakthrough they may be revealing soon. This breakthrough is part of their 3 layer financial process:
- Decentralized Cash in/out (touch point for user, any asset)
- Decentralized Exchange Network Layer
- Acceptance layer
The acceptance layer, possibly OMG ATM's, will supposedly come out soon. IMO this may be a coin and a company to watch. Jun seemed very excited about a very promising future.
Plasma Explained: Joseph Poon
Who is Joseph Poon?
Co-author of Bitcoin's lightning network and now co-author os Ethereum's Plasma.
His talk:
Poon's talked was centered around an explanation of Plasma. As noted above, Plasma is one of the proposed solutions to Ethereum's scaling dilemma.
Plasma ultimately promises 1 million transactions per second... many, many, many times more than is currently possible. This is achieved by moving away from the overly secure and inherently unscalable model of everyone confirms everything.
Before jumping into Plasma, Poon discussed channels, an idea for off-chain transactions that would ultimately be settled on-chain at finality. Unfortunately, while channels could allow for faster TX confirmation times, channels require every party to agree on state. Thus, if many, many parties engaged in said channels, they'd all have to come to consensus on state at some point. Since not everyone has the same information and not everyone is online at the same time, the system may come to a halt.
DISCLAIMER: HERE I will present a simplified version of Plasma as I understood it. I will, at some point in the near future, work through the white paper to fully understand it, and if you want the complete picture, I recommend you do the same.
Stated simply, Plasma is a construction of blockchains in blockchains where the state of the child chains are eventually committed to the root chain, allowing for thousands of state changes to be included in a single root chain commit. These child chains are basically smart contracts that act independently of one another. So, since you only care about your own financial pursuits, you are watching a whole Hell of a lot less of the blockchain. This allows for localized computation and unique rules per child chain. These child chains branch off in a sort of tree like structure:
The beauty of all this, and "the thesis of Plasma is if party starts sucking, get out." Essentially, if you are part of a child chain that turns corrupt, or malicious, withdraw your funds and move parallel to another chain.
To compile the chain, or to create the commit to the root chain, they use the famous MapReduce; they reduce all the state changes in the child chains to a single commit in the root chain.
That was a very rough explanation, and clearly I need to read up. But, that is the general idea of Plasma in a nutshell.
If any of that made sense, here is gif that "explains Plasma in 30 seconds." Note I did not create this, I found it on Reddit:
Data Unavailability: Vitalik Buterin
Who is Vitalik Buterin?
Really...
His talk:
I'll admit, at this time my brain was hurting; between Jun's talk and Poon's talk, it was a lot of information to take in. Vitalik's talk dealt with the data unavailibility problem. Fun fact, this problem is mentioned in the 2014 Ethereum White Paper:
"Another, more sophisticated, attack would involve the malicious miners publishing incomplete blocks, so the full information does not even exist to determine whether or not blocks are valid. The solution to this is a challenge-response protocol: verification nodes issue "challenges" in the form of target transaction indices, and upon receiving a node a light node treats the block as untrusted until another node, whether the miner or another verifier, provides a subset of Patricia nodes as a proof of validity."
The core of the data unavailability attack is as follows:
Basically, a mischievous node convinces the network to accept a valid, but incomplete block. This is possible because validity is provable, but incomplete is not. By withholding information, this mischievous node is able to compromise the security of the system.
There are three solutions to this attack:
- Honest majority assumption: assume there are enough "good" nodes and thus select a random coimmitte and random data and verify. However this falls short if there is not an honest majority.
- Nearly trustless client side sampling: select sampling of 100 transactions and see if 100/100 pass. However this falls short because random sampling is only accurate to a certain percent. You can never be 100% sure without 100% sampling.
- Erasure codes (state of the art): not even going to pretend I was following at this point. This is what Ethereum is going to use and here is an article from Wikipedia explaining it: https://en.wikipedia.org/wiki/Erasure_code
Conclusion
As you can see, even at a high level this is a complex space and takes a lot of research to understand because it combines networking, data structures, cryptography, economics, game theory, etc. I am reading and learning all the time and my understanding of the space gets a little bit better everyday. I've been deeply engaged in crypto/blockchain for the last 10 months and I've found that reading things and exploring topics multiple times is necessary to fully grasp what is going on.
That being said, take everything I wrote here with a grain of salt. Obviously the quotes from the Ethereum White Paper are inherently correct, but the rest was simply my understanding of what was being said. Make sure to do your own research and continue to learn.
Nevertheless, I was able to follow along for most of this meeetup and that in itself was a huge accomplishment and proof I am making some progress in my goal to be a knowledgable blockchain guru. This meetup was also an incredible experience being in the same room as three of the leaders of the crypto field. I am incredibly blessed to live in Silicon Valley and attend these events.
Hope everyone is having a wonderful weekend! Cheers and Steem on!