Sorry for going off-topic, but is there any good community I can join if I am interested only in understanding the technical side of blokchain and blockchain development, its potential use cases and pitfalls.
All of the legitimate projects have a decent technical community, and many maintain good docs and/or blogs. Personally I find Tendermint and Cosmos very interesting, and I gained a better grasp of proof-of-stake by reading their articles.
Run your own nodes and interact with them from your favorite programming language.
After you have a grasp of the existing technologies used by Bitcoin and Ethereum, I recommend learning about the issues both are trying to tackle going forward (second layer channels, proof-of-stake, sharding). Then you’ll be in a good place to understand the alternatives proposed by newer projects, like using a DAG instead of a blockchain.
Oh, and if you’re concerned about the cost of testing on mainnet, consider running a dogecoin node to start off. It’s an early fork of bitcoin, so the functionality and interface is similar, but it’s extremely inexpensive.
P2P/decentralized in general, including but not limited to blockchain: https://gitter.im/amark/gun (super friendly crowd, focuses on the cryptography part of crypto, not the currency side)
Ethereum's blockchain has a growth rate 2X bitcoin's. If it continues to grow at this pace, it'll eclipse 1 TB in size in 2018.
If you aren't verifying the blockchain that you're reading and writing to, then you're using a trusted third party.
If you're using a trusted third party, why are you even using a blockchain to begin with?
Even BitGo, a commercial payment company, has trouble maintaining datacenter servers that can keep up with the io demands of running an Ethereum node. [1] Doesn't bode well for the long-term viability of ethereum.
Bitcoin's philosophy has been, rather than broadcast every single state update to every single network participant (an unscalable network design approach[2])
> If you're using a trusted third party, why are you even using a blockchain to begin with?
This is a common misperception of the benefits of a blockchain. It's like saying, if you are trusting a third party on science, why use science at all? You don't have to verify science yourself, but know that you could repeat the experiment if you wanted or needed to. The fact that the blockchain _is_ fully stored and verified by a number of distributed parties, and that you do have the ability of downloading and verifying if you want or need to, is enough to keep the system honest.
Now this statement does make sense if you are referring to your private keys. Don't ever let any third party hold those for you.
> The fact that the blockchain _is_ fully stored and verified by a number of distributed parties, and that you do have the ability of downloading and verifying if you want or need to, is enough to keep the system honest.
How will you download and verify the chain when it hits double digit TBs?
How about 10 years from now, when the storage requirements are an order of magnitude greater than that? The rate of growth is far outstripping consumer storage device capacity...
It’s not a common misconception if trust is implied or is verified by other means then you only need to be able to effectively verify correctness and there are much much cheaper ways of achieving that.
At my startup, we have created a geth fork that uses Postgresql instead of leveldb. It took quite some effort...but we are running a full node right now. I think we are going to put in more effort there - we already implemented soft deletes,etc. Smarter people than me can probably build a better data model for the merkle trees leveraging postgres.
It's 2x slower than leveldb (if that matters to you), but given how slow a blockchain really is ...it is plenty fast enough.
I believe that it is time for developers to start thinking of single node scalability and infrastructure that is maintainable..rather than convenience.
I'm affiliated with a cryptocurrency which is using Postgres as its underlying database since the beginning. So I agree with your sentiment.
Single node scalability is often overseen, but in my opinion has to come first, before you can expand scalability network wide. It's like standard computer science practices are not being applied in the crypto world, yet.
In short: the intermediate states do not need to be stored for full trustless validation. Ethereum nodes now prune intermediate states by default. Bitcoin nodes don't even have an option to store intermediate states. Intermediate state storage is an entirely optional feature and comparing Ethereum nodes that do it to Bitcoin nodes that don't is disingenuous.
You've misunderstood the possibilities -- it's not just "store everything" or "trust someone else". You can download all of the headers but none of the data (resulting in a 27M ETH blockchain today), and then download the full blocks that you need on-demand when you want to query transactions, with no loss of safety. (If someone lied about the block contents, they'd fail to match its header hash.) This is what happens in Ethereum's "light" sync mode:
That simply isn't true. Accepting a blockchain blindly without validating is the Bitcoin SPV model. In ethereum it amounts to an undiversified risk that the two mining pools needed to constitute a majority hashpower (ethermine and f2pool) will not violate the protocol, or-- if you are accepting state with few confirmations as final-- that _any_ miner will not violate the protocol.
Headers are fingerprints / unique hashes. If someone else has already derived account balances to a particular point, it may be enough to avoid duplicating the chain.
No, pruning in ethereum means not storing old states (=results of executing all blocks at height H), not removing old blocks. As of now the bare blockchain + the state takes only about 20+2GB. It takes more on a live node due to db space amplification (45-50GB in parity), but that can theoretically get very close to 1x with future updates.
Smart contracts can have arbitrary state, but in general, yes. An archival node stores the state for each block which is only useful for block explorers and similar. That's indeed likely to take 1TB in 2018 - hardly a problem.
This is extremely widely misunderstood, one of those rampant FUD topics.
Archive nodes in Ethereum are almost completely superfluous.
An Ethereum archive node is not the same thing as a full node.
Archive nodes add zero extra security to the network. They are only useful for historical analysis of past states.
100% of the blockchain information is stored in non-archival full nodes.
The Ethereum system is a series of transactions that modify a state. The system is completely defined by the transactions. The latest state can be derived from them.
An archive node is a node that stores all past states for efficient retrieval.
...so, we're back to trusting a set of centralized parties, then? What if those get wiped? Altered (though that seems less likely)? Is such an archive a fork vector?
I wrote a blockchain explorer on Bitcoin as a technical exercise, and the intermediate state thing caught my attention, too. If all copies of a block disappear and all you're left with is a hash, what do you have? A complete blockchain?
>Even BitGo, a commercial payment company, has trouble maintaining datacenter servers that can keep up with the io demands of running an Ethereum node.
That company lost 120k of Bitfinex's BTC to a hack, the exact scenario it was apparently created to prevent. Their struggles reflect their competence level: especially the part about _directly_ using network storage, apparently genuinely not realizing that the main point of local instance storage is to function as a last cache level exactly for situations like these.
If you aren't verifying the block chain you don't have to rely on a trusted third party. You ask a third party and then check with a couple other third parties to verify what the first gave you. Big difference.
Having authority be federated is a vast improvement. It's not hard to understand that I might be willing to pick an authority I trust out of a pool of the entire globe when I might not be willing to trust the authority of the US government and a handful of proximate banks.
Well that's exactly what both cryptocurrencies are currently working feverishly to solve.
Bitcoin's idea is to use Lightning Network to keep the extreme majority of transactions from ever having to hit the blockchain. And it's also why the blocksize shouldn't be increased like some forks are doing, because in 100 years (or even 5 years) the size will be unmanageable.
I believe ETH has something similar, but I'm not knowledgeable enough about that ecosystem to say either way.
It's clear to everyone that the blockchain as a "data structure" isn't scalable to anything resembling "widespread usage", and that it will be a hard requirement to figure out how to either quickly and safely "prune" information from a blockchain, or get most of the transactions to stay off of it somehow.
Also, I'm sad that most of the replies to your comment are jokes or comments about how it won't matter, or how you are dumb for even asking the question. It seems when it comes to cryptocurrencies HN is just as bad as other forums online that everyone resorts to insults and "witty" one liners.
The eth devs are busy working on sharding - the same idea as traditional databases like Mongo where a primary key decides which node the data will reside. The main problem here is that a contract residing on shard A might reference a contract on shard B (much like a join between 2 shards). They are approaching this by using "transaction receipts" that would be passed from shard to shard. https://github.com/ethereum/wiki/wiki/Sharding-FAQ
Indeed - Raiden is all about payment channels - funds are deposited on the main chain and then payments can be sent over channels with no fee. Only in the case of dispute or cashing out is the main chain used to resolve the conflict. This means you could make many transactions per second of very small amounts (useful for things like gambling sites or micro-payments for content). Micro-Raiden is already active which are one-to-one payment channels - the full Raiden network is not yet live but will facilitate one-to-many channels.
But unless a node needs to execute every transaction or easily query historical data, there’s really no need to store the entire chain. This is where the concept of a light node comes in. Instead of downloading and storing the full chain and executing all of the transactions, light nodes download only the chain of headers, from the genesis block to the current head, without executing any transactions or retrieving any associated state. Because light nodes have access to block headers, which contain hashes of three tries, they can still easily generate and receive verifiable answers about transactions, events, balances, etc.
The reason this works is because hashes in the Merkle tree propagate upward — if a malicious user attempts to swap a fake transaction into the bottom of a Merkle tree, this change will cause a change in the hash of the node above, which will change the hash of the node above that, and so on, until it eventually changes the root of the tree.
"Peter Todd, a Bitcoin Core developer, concerns what we can say is a fundamental technical argument from small blockers. They argue we can not scale on-chain, because we can not have light-client nodes, because we can not construct what is called fraud proofs."
Vitalik Buterin and Peter Todd Go Head to Head in the Crypto Culture Wars
Well if Bitcoin Cash gets to VISA level transactions quantity they will have around 1GB block every 10 minutes, who will be able to run a full mining node?, 2 to 3 corporations worldwide, probably centralized in some geographical region for lower communication latency.
Using a 3TB, $70 drive from NewEgg as an example, HDD costs for full 1GB blocks would be $3.36/day, today. Surely more than 2-3 corporations can afford that.
The RRP of a terabyte of hard drive on NewEgg has almost nothing to do with the cost of provisioning an additional reliable terabyte of datacenter storage + IOPS
The "Gigablock Initiative" presented at the recent "Scaling Bitcoin" conference tests exactly that. They found that Bitcoin Cash can easily scale on chain to VISA levels using standard desktop machines.
But that's with a full copy of the state of every block, which is redundant and only needed for efficient historical queries. If you just want to fully verify the current state, all you need is the block headers, the current state, and all the transactions, which adds up to about 30GB.
Full nodes include nodes that don't store intermediate state. Storage of intermediate state is optional in Ethereum. It's not even possible in Bitcoin. An apt comparison is between Ethereum full nodes that don't store intermediate state and Bitcoin full nodes.
Would you please stop posting flamebait to HN? Obviously this is the last thing we need here. We've warned you many times about breaking the site rules.
I appreciate the solid submissions you've posted but if you continue to wreck HN threads by trolling them, in effect if not intent, the negative outweighs the positive.
Look at this thread... the only thread on this entire submission, all stemming from the same post. I’m not the one posting flamebait, and I wasn’t the first to react with incredulous disgust.
If you want to improve this site, I’d start to crack down on non-technical submissions about cryptocurrency. They’re as bad as stories about Trump for predictable bullshit, and equally predictable squabbles along ideological or self-interested lines. It’s a cross between boring and grotesque that so much time is spent here saying essentially nothing about the latest ICO scams or currency forks. What part of this is intellectually satisfying or engaging?
Worse, the daily dozen+ front page stories about this crap displace genuinely interesting submissions and discussions.
Such objections and advice carry no weight when you bring them up just to evade your own breakage of the rules. If you want your ideas about HN to be taken seriously, first take basic responsibility and then show that you can use this site as intended, by actually doing so.
You answered a question that the user didn't ask. If you feel they won't be around, that's fine. But if the discussion is about how hard drive usage will scale over many years, injecting "it won't matter" is a pointless comment. It not only doesn't answer the question, but it provides basically no information other than your feelings on a subject.
I don't know what the world will look like 83 years from now, but I would bet money that the world is using crypto for currency. How about we make a bet on it? You know what, let's place our bet in a time locked smart contract and have the money automatically disperse to our descendents in the year 2100.
