Thoughts on the Ethereum Whitepaper
Thoughts on the Ethereum Whitepaper
So I really enjoyed this one primarily because of the talk with Merkle Trees. One of my concerns tends to always be the validity of data (blame it on my infosec minor). Merkle trees really seem to solve this issue in an interesting way. All of the nodes have to agree that something is valid, but there is also a level of a “checksum” built into it to make sure that everything is in there that should be and nothing has been changed.
It is interesting that the whole disk space issue on Bitcoin is brought up here. I remember reading about different discussions on how to handle the issue of the exponentially growing size, but a lot of the ones I have read have really only ever seemed to be theory and never put into practice fully yet.
(To continue now that I have looked at the Ethereum 2.0). So it seems like they are trying to solve this through sharding. Sharding is something that I have always thought was super cool (and one of the reasons why I enjoy using Mongo with really large datasets). It is also something that is similarly used sometimes with Virtual Machines in a Data Center (not exactly sharding but super similar idea. In trying to do some other research with this I happened upon this article: https://blockonomi.com/sharding/ which really helped to explain it. However I also ended up on this https://medium.com/prysmatic-labs/ethereum-2-0-casper-sharding-development-update-13-prysmatic-labs-2ef6593ea22f which brought up some interesting pieces that I wasn’t thinking of. With the whole idea of ETH being stored on different shards. I am probably jumping in too deep for this, but it was something that brought up some interesting questions.
Yup, it’s not an entirely novel idea, but people are still nervous about actually applying it to block-chains (probably rightfully so). It’s likely just one of many solutions to layer 2 scaling.
Once we scale up Bridge Academy over time, we may need to shard our batches into different groups
- “…Finally, there are applications such as online voting and decentralized governance that are not financial at all.”. Given that Ethereum transactions cost money (gas), wouldn’t it be a little impractical for non financial application, say for example (supply chain)? in the case of supply chain for example, it wouldn’t be relevant for involved parties (except for the end customer) to pay for transaction fees for the purpose of creating a single source of truth (used for backtracking the parts involved in automobile manufacturing, or the harvesting, roasting and packaging of coffee for example); same case in voting. With this in mind, how exactly would advocates of Ethereum tackle this problem?
I think most Ethereum advocates are also in favor of layer 2/3 solutions for these kinds of things that don’t require gas to settle, but can rely on other methods where immutability and 100% censorship resistance isn’t absolutely necessary.
Another recent proposal is for ‘gasless’ meta-transactions: https://medium.com/@austin_48503/ethereum-meta-transactions-90ccf0859e84
If you are interested in the cutting edge of UI/UX and frictionless DApp experiences, I would recommend reading these two articles:
Went through the Ethereum white paper and it gives more practical approach of blockchain and decentralized system and how it can be used in different fields. read somewhere the Ethereum mining is virtual mining, i.e not like the bitcoin we don’t need a physical resource for it. is it true. if yes, how it works, how new ethers are generated.
I’m really digging the Casper POS consensus algorithm. However, as stated here: https://blockgeeks.com/guides/ethereum-casper/, one of the goals of POS is to achieve decentralization (contrasting POW, as 65% of the cpu power is owner by five mining pools). My question is, won’t making the whole consensus weighted more towards having a bigger stake make it more favorable towards nodes with higher economic power, beating the whole purpose?
In short, Yes. This is part of the tradeoff in moving to a POS system which is why Ethereum is trying to transition first via hyprid POW/POS model.
I believe the minimum stake to validate transactions in the POS model is 32 ether, which isn’t that high of a barrier at today’s prices as it was last year
what I would do if I would win the lottery…
I found the concept of using a Merkle tree interesting, for the main purpose of sustainability due to the long string of transactions. I was wondering if it could be a problem that the nodes optimize disk space by pruning the bottom branches/transactions. If all the nodes were to decide to optimize over time, wouldn’t we lose a lot of history of transactions that could be helpful? Let’s say a dispute arises between a payer and a payee, and this transaction happened n days ago. Payer said they paid; payee doesn’t believe it (maybe they forgot it happened?) and refuses to ship the item. If it happened long enough ago isn’t it possible that the transaction would just not exist in any of the nodes due to the pruning process? From looking at it there wouldn’t be any way to confirm/deny that this transaction actually took place, and no way to run the transaction through the state function to validate it up to the root (on the currently accepted branch).
This is a great paper to introduce how Ethereum can be use as the foundation of building dApps.
In the white paper, it discusses the usage of smart contracts for financial derivatives as a common application, however I’ve read about ETH’s honeypot weaknesses. This might send me down a rabbit hole in searching as to how this happens. Some of the biggest hacks were from ETH based applications. Is this because developers utilize easily hackable code? In one article I read, " The Sneakiest Ethereum “Scam” (honeypot) Ever", the author goes into depth about how he/she baited hackers a line of code:
uint8(sha3(now, block.blockhash(block.number-1))) % 20 + 1;
I am curious as to if the ETH track will go into more depth around this sort of thing!
I think sharding is a a great way to attack the scalability issue in ETH 2.0. As it stands right now, ETH is secured and decentralized, but the scalability issue is a big problem. Knowing what I know now, developing apps using ETH and not understanding this issue would be a huge rookie mistake on my part!
The point of Sharding is every validator have to keep track of at a minimum of all the headers of every single shard. You basically have to be a lie client of all the shards. And then as a validator, you will be called upon a randomised basis to actually download the block data. This is quite drastic scalability in the sense that total throughput of the system is going to the throughput of one individual shard multiplied by the number of shards.
Ref : https://www.youtube.com/watch?v=J4rylD6w2S4
The Ethereum White paper was pretty interesting. It was a bit longer than the Bitcoin paper but did a really good job of outlining some of the shortcomings of Bitcoin and how Ethereum attempts to fill in the blanks. Ethereum 2.0 looks exciting and like @nick I think sharding sounds like a pretty cool way to deal with the current scalability issues. I’m going to go through the links he shared as additional reading.
The example of using Ethereum as a way to implement derivatives contracts is particularly interesting to me as this was an application of the Ethereum blockchain that immediately jumped out at me when first learning about it. Out of curiosity, are there any known crypto-derivatives that anyone has heard of?
Abra makes use if crypto derivities using the bitcoin blockchain.
dy/dx is one to look out for on using ethereum
Thanks! Will take a look at both.
Thanks for links! The eth 2.0 video had some hand waving on the concepts so these will be helpful.