After looking through code, a number of concerns are also raised:
- key pairs use RSA - identities are based on MD5 of RSA public key - no p2p protocol for nodes - lack of proof of work (more on that below)
As-is, the project is a rails application which references accounts by MD5 of the public key, a postgresql database, and a REST client. In other words -- basic rails ledger app plus some PKI.
I see a significant issue with hyperledger, in that the pools are, by nature, private. The only verification a client can perform is the SSL certificate. A pool owner, if they wish, could change the account balance on all of their private nodes and there would be no public record of the change or the previous history. Yes this would require collusion of some kind, but even for 10k nodes, such data can be changed in seconds. Without a blockchain, how could anyone prove otherwise?
I see the potential for companies like quickbooks, paypal, or even banks, to create public REST interfaces for their account ledgers. This seems inexpensive for a bank to do (compared to a p2p network), and, we'd have the trust of the bank. This is money after all, so, I'd trust the bank over a psuedo-private network.
Looking forward to see how hyperledger will approach the problems described above. I would be surprised if the end-result isn't similar to bitcoin.
Thanks for your comments! There's obviously a bit of a gap between the proposed details and the implementation at the moment. Having said that, the framework for all of the features you mention are there at the moment, even if the implementation could do with some improving.
Our contention is that replicated HTTP services can provide a trustworthy base for a payments system, so the system is based on REST interfaces and signatures. There's no custom p2p protocol, it's just signed, broadcast HTTP messages. The current staging pool is running on 4 nodes and issuances and transactions aren't processed until at least 3 of them sign the message. The nice thing about signed HTTP messages is that there's a lot of infrastructure and tooling out there that can take advantage of this right off the bat.
The pools themselves aren't inherently private (although they could be, and at the moment we're the only ones running staging nodes) so there's not really a pool owner. Healthy, trustworthy pools should have nodes being run by completely disparate parties, and that's something we're working on getting running.
As for verification, all transfers and issuances are signed by the clients, and all requests are signed by the consensus nodes, and all of that information is public. The CLI doesn't really expose this very well and could definitely do with some work, but basically if queried, a node should be able to show the complete list of transactions that lead to a balance, each one signed by the clients and the nodes. If it can't do that, it's a misbehaving node and should be removed.
One thing that is missing in the code at the moment is primary/replica states and ordering of transactions. That's our next big chunk of work. Proof-of-work does a few things in Bitcoin, but ordering transactions is a big part of that and we think that a primary/replica system can do that without the overheads of proof-of-work.
Finally, I don't quite follow your concern about RSA public keys. I was thinking of moving to NaCl for keys/signatures, but that's an implementation detail at the moment and the protocol could support multiple algorithms. I think 2048-bit RSA keys is okay for now. MD5 signing of the public key is also an implementation detail and might be changed in the future, but I feel it's a pretty reasonable default to start with.
Hope that answers your concerns! Let me know if not.
Bitcoin is peer-to-peer. Anyone can join as a peer at any time. When you want to spend some Bitcoin, you sign a transaction and send it to your peers, who relay the transaction to other peers if the transaction looks valid to them. But the transaction isn't considered "committed" until it becomes part of the blockchain.
Peers in the network race to create the next block in the blockchain by proof of work. Whoever creates the next valid block first wins, but for a block to be valid it has to contain a solution to a CPU-intensive problem. The reward for winning the race to create a block is that you get to "mint" some brand new bitcoins to yourself, though the number of new bitcoins in each block is predetermined on a deflationary schedule. Anyone who controls over half of the CPU power can control the blockchain.
Hyperledger is not peer-to-peer, it has "nodes" which have to be invited/allowed on the network. Each node has a public/private keypair, and for a transaction to be valid it has to be signed by a node. Nodes only sign transactions if they can achieve consensus with other nodes that the transaction is valid and doesn't double-spend. So you don't have to wait for the next block to get transaction confirmation, you just want to get a node's signature on your transaction
The "Practical Byzantine Fault Tolerance" consensus algorithm can continue to function even if up to 1/3 of the nodes are actively trying to subvert it. Apparently bad nodes can be detected and expelled (how?), but if more than 1/3 of nodes suddenly become malicious, double-spending is possible. So you don't want to invite a node unless you trust it.
Also, instead of a predetermined schedule for minting new coins, the model is that someone can issue units at any time. This must require a consensus too?
Benefits of Hyperledger vs. Bitcoin: Hyperledger can confirm transactions faster since the PBFT algorithm can achieve consensus a lot faster than it takes to build a block (or 2 or 3, to be safe) in Bitcoin. When a transaction is signed by a node, that is a positive confirmation that it was accepted by the network, rather than Bitcoin's less dependable "longest chain wins" rule.
Benefits of Bitcoin vs. Hyperledger: Bitcoin, being truly peer-to-peer, does not require the same management of deciding what nodes to trust and allow onto the network, and expelling them when they turn malicious.
I think it's better, instead, to use bitcoin for some activities and to use a central payment processor for other activities. The central selling points of Hyperledger are "transaction speed" and "low fees"... Why not just use centralized Bitcoin off-chain transactions for these situations, which are even faster and likely even cheaper?
Usually if you want a transaction to be confirmed in under 10 minutes and for a small fee, you're dealing with a transaction under 100 dollars, in which case trusting a central server that is driving off-chain transactions is not a problem.
EDIT: Reflecting more on this, I think a case can be made for a hyperledger-like system beyond a centralized off-chain mechanism, but the problem it solves is small enough that I couldn't imagine using it in the short term. In the long term, something like this may be useful.
If so, is that much different from using a central service and trust its creator?
Yes, you must have some trust in the ledger owner, although, as mentioned in another post, depending on the type of asset it may not be such as issue.
We built the system so that the issuing rules and payment guarantees were separate because we think that's a good thing. We have some ideas as to how we can improve trust and transparency in issuing parties in the future, but that can evolve separately from the payment rules.
Also, we think there is a benefit to payments not being centralised, even while issuance is. For a start, the ledger is signed by multiple parties which increases trust and resilience against faults (malicious or not). From the other point of view, if you are an honest issuer (and most should be!) you don't have to worry about creating a trustworthy and reliable payments platform.
Then I fail to see the advantage of a decentralised system, as we can let the ledger owner sign each transaction, instead of a consensus.
> although, as mentioned in another post, depending on the type of asset it may not be such as issue.
Can you elaborate or point me to that comment?
> Also, we think there is a benefit to payments not being centralised, even while issuance is. For a start, the ledger is signed by multiple parties which increases trust
I would consider the ledger owner’s signature more trustworthy than multiple third party signatures.
> and resilience against faults (malicious or not).
Making it decentralised has a much larger attack (and bug) vector, so I wouldn’t conclude that decentralised in itself is an advantage (which I think is really what you are saying).
The main one being that there is no native currency like XRP, so there is no risk of a similar situation to the current fiasco arising.
hyperledger is designed to be far more light weight and flexible than Ripple, meaning that instead of just being a conduit to trade other assets, hyperledger allows organisations to also issue their own assets, which they have complete control over.
We also have a different notion of pools. Anyone can create their own consensus pool with its own membership requirement rules or features, such as private transaction.
We achieve consensus by a slight different method. More info on this to come, please check the FAQ: http://www.hyperledger.com/faqs.html#ripple
Currently we are a small team of two, myself on the business/marketing side (we will be building commercial products on top of the open project, just as any user could) and feichtinger who is the main technical side. A bit more info on the contact page. Happy to answer any specifics here.
Actually there is. The Ripple fiasco arised because the creator (jed) owned a large amount of XRP, and decided to sell large quantities of it, hence crashing the market. In hyperledger, organisations can issue their own assets, therefore can own a large quantity, therefore can crash the market by selling a lot.
Hyperledger as a platform is technically independent of and will survive such market crashes, but this is kind of irrelevant since the currencies/assets it enables the creation of are exactly vulnerable to all the same flaws that XRP is vulnerable to. Ultimately the users of hyperledger don't care about the platform, but care about the value, fungibility, liquidity of the currencies/assets.
Furthermore, it seems to me hyperledger is not decentralized at all. IIUC the issuance of the currencies/assets is 100% controlled by the rules defined by the organisations that created these currencies/assets, so who would guarantee me for example that organisation X is not going to issue 100 billion more units of currency Y tomorrow?
What prevents an malicious actor from getting 34% of nodes, and then turning them all bad at the same moment?
The wording on that could be improved a little because there's a bit of a distinction between total computing power and number of nodes.
It's a proven result that in asynchronous systems with potentially malicious nodes, 1/3 is the maximum number of faulty replicas that can be tolerated. Here's a paper with a proof: http://zoo.cs.yale.edu/classes/cs426/2012/bib/bracha85asynch...
Bitcoin mixes things up a bit by also taking into account total computing power, but is still vulnerable to attacks where more than 33% of nodes are controlled, like selfish mining: http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/
If more than 33% of nodes are compromised at the same time the good nodes will not accept bad transactions, they will simply wait until the consensus pool is fixed or removed and then continue normally.
Of course, with enough nodes it should be very unlikely for an attacker to get control of that many nodes at once.
I wouldn't bet on it. Look at the warnings that have gone out about the last couple of Rails RCE vulnerabilities: attackers can scan the entire Internet for vulnerable apps in a faster time than many sysadmins can get the upgrade deployed. Now, imagine this: a potential attacker, ahead of time, finds a way to reliably remotely fingerprint the version of Rails you've released as hyperledger. One scan later, they're sitting on a list of the IP addresses of some large proportion of hyperledger installs. All they now need to do is wait for the right vulnerability to be announced (or find it themselves), and then it's a race to gain control before a) the Rails team publishes a patch, b) you release a new version of hyperledger with the patch applied (or can announce that the patch doesn't break things via a gem upgrade), c) more than 66% of the sysadmins jump on the announcement. In the time for a), b) and c) to happen, they need to i) run a single exploit, and ii) simultaneously generate a bad transaction, across the servers they now control.
a), b), and c) are humans. i) and ii) are a for loop in a single bash script. That's not a race I'd want to be on the wrong side of.
> bad nodes are automatically detected and expelled quickly
I'd be curious how the detection mechanism works
(I mean, not exactly this, but something like this.)
i am wondering, when everything is free and open-source here, how is the business model?
> premiumpool is our commercially supported pool. Restrictions and requirements for operating a consensus node are more stringent and claims made by ledgers are audited. For more information, please Get in Touch
As the other commenter noted, our only plan to directly monetise the project is via a commercially supported premium consensus pool. However, long term we do plan to set up a commercial entity to build on top of hyperledger (in the same way that anyone could) to offer various related services. This are all in far too early stages to share just yet though, I'm afraid!
First: congrats, this looks fabulous.
Second: can you walk us through one real world example of how a startup might use Hyperledger to do something useful?
Of course, people who want to see the pool fail could run malicious nodes, but given appropriate membership restrictions and that fact that all an attack can do is pause the pool temporarily the incentive there should be pretty low.
The service is currently running on four nodes:
http://hyperledger-staging-1.herokuapp.com http://hyperledger-staging-2.herokuapp.com http://hyperledger-staging-3.herokuapp.com http://hyperledger-staging-4.herokuapp.com
You can create a ledger by POSTing to /ledgers at one of those 4 nodes and it will be replicated on the other nodes. The CLI is very rough at the moment but is probably the best place to see how to construct a valid message: https://github.com/hyperledger/hyperledger-cli/blob/master/b...
