Show HN: Hyperledger – Open Payments Protocol

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.

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.