|
Hyperledger's home page talks about a protocol, pools, consensus, security, and decentralization, however, none of those features exist in the codebase. Proof of work and distributed networks are why bitcoin and others are more complex than a list of node URLs and a simple database model. 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.