How to create a private Ethereum network
omarmetwally.wordpress.com
omarmetwally.wordpress.com
"The validators are known, so any risk of a 51% attack arising from some miner collusion in China does not apply."
I guess you could still have attack from authorized nodes in your own organization?
Make it easy to do but also easy to undo anything, while also having a very large amount of transparency in the system so any "bad actor" can be dealt with swiftly.
That seems to work for the banking system, where any malicious transactions are easily "reversed" (often just reversed on one side actually, 'paid for' by insurance / banks) and a large amount of auditing which makes it possible to clamp down on the bad actors quickly.
Abusing the system then no longer becomes a technical challenge so it removes the possibility that someone with the right technical prowess can "break" the system. Robbing a bank is the easiest thing in the world, just walk in and ask for money, it's getting away with it that's difficult.
I work for a bank on blockchain projects. It's almost never this simple. You'd be suprised how much banking is paper based right now for the simple reason that no party wants a central solution controlled by any other party.
A lot of these companies are doing experiments using private blockchains (like the private ethereum network linked in OP). However depending on how much you trust the "other" parties allowed to mine (or sign blocks), you might still have the risk where one or more conspire against you and 51% attack you. Periodically putting a blockheader of your private chain into a public blockchain would be a great solution to this, as pulling off a 51% attack on bitcoin is rather hard.
That's just wrong. Dangerously so. Maybe I'm just missing something in his protocol spec and he didn't really mean mining...
I've discussed this attack vector in more depth here[1]. Even if you made the mining function signing the block with your sk it'd still be wrong. Even if you forced the sk holder to have that same sk protect something really valuable, it would still be wrong... just have a larger disincentivize.
The whole point of mining is that it's non-auditable (w.r.t. who is physically mining) -- the only real metric you get is the speed of success which you can always mask by not releasing a block immediately. That's why PoW is a cockroach of a consensus protocol.
In the "we roll a dice to see who gets to append to the ledger next" metaphor for consensus, deterministic and PoS both require you to know the number of sides the dice have before you roll them. In PoW, you don't figure out the number of sides until after.
This is an aside, but of the 26 currently active bitcoin mining pools, you'd only need to compromise the top 4 to have >50% mining power. Perhaps a little social engineering could bring that down to 3.
I wonder how difficult that would actually be.
eg. A 'MyCoin' miner grabs the latest 10 blocks off the main, say, Ethereum blockchain, and includes those hashes as proof they began their block mining _after_ those main blocks were mined, then adds their own proof-of-work on top, winning the block-solve lottery to add the next block to the blockchain.
This could potentially reduce the amount of relative advantage a dominant miner has ( others can provide a math analysis )
This approach can also save electricity, as it puts the miners on a mutual 'duty-cycle' where MyCoin miners are only busy running cryptohashes for a fraction of the time between blocks.
Another nice side-effect of this 2-tier mining is that the block generation times are spaced more evenly over time. [ They move towards a normal distribution around the average time, rather than uniformly - a result of the 'law of large number's, which states roughly that the average of uniform 'flat' distributions approaches a normal bell curve around the mean ].
Currently Bitcoin blocks sometimes arrive after 1 minute, other times only after 19 minutes, with mean 10mins maintained by adjusting difficulty. So the bitcoin time between blocks variance is high ( Litecoin adds blocks 4x as often @ 2.5mins, Ethereum ~10secs on average, but all with quite high variance ) which can surprise users.
In this case, because there is centralisation of trust, the 51% attack is not possible as there is only one mining node or, otherwise, only one "actor" can actually add blocks to the chain with as many nodes as needed. This is the case with Ripple, for instance.
The trust model is different but all other capabilities are kept intact, so in the case of Ethereum you would still have the distributed singleton and immutable code that will always execute in the same way anywhere in the network, at any point in time.
For established businesses entering the space, the privacy of closed network compensates the absence of "secrets" to some extent. It is also quite useful as a training ground because of course the technology is still in its infancy.
Some paper and a pen might solve your business problem but you shouldn't extrapolate that all business cases would be met with those capabilities.
I do think there is plenty of room for private blockchains, but the use cases will be specific to the needs and constraints of the stakeholders.
There's a difference between "not needed" in the sense that I don't need a calculator when I have an abacus, and "not needed" in the sense that I don't need an abacus when I have a calculator.
> the use cases will be specific to the needs and constraints of the stakeholders
Yes, and people are asking for suggestions of what those use cases might be. If you can't think of any, that suggests we might be looking at an abacus, not a calculator.
- One case would be when a corporation wants to have 2500 TPS with finality in 3 seconds using the current ethereum software, unchanged. (scalability)
- One case would be when a large-enough-corporation needs to share master data and reference data of business critical assets through different subsidiaries and third parties. (privacy)
- Remember intranets? Sometimes decision makers simply want a watered down version of a great thing. (stability, control)
If you care to include commercial DLT products, then the use cases will be different again.
What's the killer app? Sorry to be annoying but I honestly don't see why an CIO would choose a blockchain over more traditional options for anything at all. I've been following Bitcoin and ETH for many years and I've been thinking about this a LOT and I just don't see it.
I'd be happy to discuss further in private (chat/skype), but my "professional muscle memory" tells me that the only sane way of looking at a piece of technology is through its capabilities. When CIOs look for capabilities that can be met by blockchain then finding a business case becomes straightforward, otherwise it will be shoehorning as you say.
I'm not sure what you mean with sybil resistance in this context though. Do you mean to say that PoA reduces the "51% attack" vector?
Anyone malicious that connects to the network can easily overpower the existing validators. Sybil resistance is only the case if validators compete with computation due to economic incentives. In consortium network the native tokens have likely no/low value.
With PoA there are rules according to which validators are added/removed and limits on block issuance that ensure fault tolerance.
On a public blockchain, you need a proof that all nodes are acting in the best interest of the network because there is no way of stopping anyone from joining. The economic incentives play a huge part here as you mention.
On a private chain, you'll have some form of registration or centralised auth which prevents "unknown" nodes from joining in the first place. If mining is centralised, that means that trust is established "off-chain" so an external sybil attack would not be a real threat.
Regarding the power usage and difficulty increase over time, I guess you could keep the resource usage low for some time, but you'd need to re-write the client software to prevent and increase in proportion to the number of blocks created, which could have a negative effect on the network synchronisation, or rate of inflation (coin issuance) if there is a token involved.
With this PoA you can keep a well functioning chain and kick misbehaving nodes (up to 50% of validators for this consensus engine) in due time.
In order to re-write historic transactions, an attacker would need to convince other participants to accept the new chain as valid and drop the old one, which is would be prevented by the off-chain trust model in the first place.
A powerful "rogue" node that starts producing blocks with different validation rules would be automatically ignored by other validator nodes who would not recognise the blocks as valid, so here again the risk of a successful sybil attack is limited.
Fault tolerance seems to be a red herring here because but I would rather ask you to expand on what you mean.
With PoA there is no such ability, since the canonicality is not abusable. Furthermore addition and removal of nodes can be decentralised and determined according to any rules (since validators can be specified in a contract). This makes it possible to include validators based on something like majority voting.
It seems to me that a successful attack on a private blockchain requires the attacker gaining access to both a "pre-approved" node and having the hashrate majority needed to ensure its blocks are generated faster than the rest of the network combined.
Some background: https://coinjournal.net/vitalik-buterin-on-misconceptions-in... and https://www.reddit.com/r/ethereum/comments/48m9n6/vitalik_bu...
Is there a better alternative?
Personally I don't think there's a real risk of exposing your real Ethereum wallet by setting up a testnet, as long as you only let localhost connect to it.
Since you are building a private network, you may also add a small script so your nodes only mine on demand (i.e., when there are new transactions) which will reduce the power usage on your machine and avoids having the difficulty increase too quickly.
Save the script below as mine.js (for instance) and then in your geth startup command, include it as `geth --networkid <your_networ_id> ...other params... js ./mine.js`
`var mining_threads = 1
function checkWork() { if (eth.pendingTransactions.length > 0) { if (eth.mining) return; console.log("== Pending transactions! Mining..."); miner.start(mining_threads); } else { miner.stop(); console.log("== No transactions! Mining stopped."); } }
eth.filter("latest", function(err, block) { checkWork(); }); eth.filter("pending", function(err, block) { checkWork(); });
checkWork();`
I picked up this "trick" from Embark framework (https://github.com/iurimatias/embark-framework)
One addition--Geth 1.6 released a very nice interactive tool called puppeth that creates genesis blocks and provisions testnets, I've found it easier than doing everything myself.
Although once again there really wasn't any tutorial or documentation about puppeth for Ethereum beginners, the only reference I could find was a Taiwanese Ethereum meetup blogpost, which was mostly in Chinese.