Hacker News Reader

Comment by subway | Hacker News Reader

Enterprise Ethereum has almost nothing to do with Ethereum the public blockchain, or crypto-currency. Ethereum based blockchains (that is based on Ethereum the software, not the canonical global instance of that software) provide an ability to create an auditable log of events.

Those events might be "who accessed my credit card account and when" or "who requested access to my health records and when". These chains can exist entirely independently of of the global "Ethereum" chain, and can operate entirely without the concept of a crypto-currency (aside from using it as a scheduling mechanism within your blockchain cluster).

People need to stop getting hung up the cryptocurrency aspect of blockchains.

View on HN

> Ethereum based blockchains provide an ability to create an auditable log of events

If all they want is a log of events, why not use a tried and true database whose performance is more well understood? MySQL, Cassandra, whatever.

You can add the ability to audit the tables by signing data updates with public key crypto.

By using a blockchain, you enable auditing organizations to participate in the authentication process. For instance, I might publish a private message to the blockchain that is an authentication request to resource X. A smart contract would then act on that authentication request, and publish either an ACCEPT or REJECT message. By bringing auditing organizations into the blockchain, every authentication attempt is sent to the auditing organization before access is granted.

The key is that every transaction must be made known to the auditors before it is acted on. By logging to a traditional db, you're at the mercy of the party responsible for sharing out those logs.

Interesting. Seems like potentially cool ideas in government and politics for transparency.

Here is your schema:

DATA | auditor_sig

------------------

Now:

a) Assume 3 components: client, server, auditorService

b) How to write to server:

  1- client sends DATA to auditorService

  2- auditorService signs DATA and returns S(DATA)

  3- client writes (DATA, S(DATA)) to server

c) How to read:

  1- client reads (DATA, S(DATA)) from server

  2- client verifies S(DATA)

  3.1- valid? -> continue

  3.2- invalid? -> delete DATA from server

There are ways you can configure this to make either of these services have more weight (I made the server weak in this setup), and you can also give read access to everyone if you want it to be public (and only a subset of clients get write access). You don't need a blockchain.

Federated blockchains allow multiple parties in an industry (for example) to maintain a shared trusted database, with no single owner, or single point of failure. (Also, changing immutable data or posting fraudulent transactions requires collusion between multiple parties.)

This is why many large industries like healthcare and finance are actively exploring this space.

Distributed databases can be configured to work that way as well.

Why do you need a proof-of-work blockchain? With such a small number of participants doesn't that weaken it's integrity to attacks, especially without capital incentives?

Please someone answer this.

There's nothing that ties a blockchain to proof of work. Proof of work just just one consensus protocol. For instance, JP Morgan's Quorum is working on Raft based consensus. https://github.com/jpmorganchase/quorum/blob/master/raft/doc...

The nodes are federated and you're still calling this a blockchain? What definition of the word "blockchain" are you using? Is this not more commonly called a "distributed database"?

To me, "blockchain" implies the individual nodes don't trust each other, while "distributed database" does.

A "blockchain", taken as a primitive, is essentially an append-only (geographically-)distributed database.

Consider: a Starcraft 1v1 ladder match is, by this definition, synchronized using a "blockchain", whose participating nodes are the two players' computers and the auditing ladder-server instance. That's not a reductio ad absurdam; that's actually what you should be picturing when you say "blockchain" generally: participant nodes, an event stream chunked into blocks, and a consensus mechanism for validating blocks.

Proof-of-work is just one consensus mechanism for blockchains. Mutually-agreed arbitration oracles (as above) is another. First-claim using a global hierarchy of signed-timestamping servers is a third. Etc.

Replying to myself since we hit max comment depth (probably an indicator it's time to move away from this thread anyway). but to address the sibling reply by hudon, yes, a blockchain is a form of a distributed database (maybe highly replicated data base is a better term since every node has the full working data set).

The key trait of a blockchain is that each new entry cryptographically verifies all previous entries. At the end of the day, yes, a blockchain is a distributed db. It's a distributed db that never forgets.

> The key trait of a blockchain is that each new entry cryptographically verifies all previous entries

I see what you're saying. Basically: distributed database + signatures + merkle tree = blockchain.

I usually use this definition: decentralized and sybil-resistant database + signatures + merkle tree = blockchain.

So I think the key trait that turns a distributed database into a blockchain is not the merkle tree, but is its decentralized nature. Anyone can be a transaction validator and no one can prevent transaction validation.

Traditional distributed databases require all nodes to be trusted to achieve consensus (e.g., with Paxos, Raft, etc.) Proof-of-work allows for consensus to occur even if there are malicious nodes -- for up to half the hashrate, which means that major collusion must occur to do something fraudulent.

In these industries the number of participants are in the hundreds -- past the point at which you can trust everyone.

This doesn't work in reality. If you have two companies that need to work with common data it's currently very complex and costly to ensure that both parties can trust the data. That's why trust banks are so big in finance (e.g. Bank of New York, State Street) because it's often cheaper to have a third party you can trust rather than establishing protocols between two companies that auditors approve.

Blockchain can save a lot of money here by making the trusted third party obsolete.

If I understand correctly, this is basically a database but in a merkle tree form + crypto. There is also no proof of work as it is not needed.

Maybe the client has key pinning baked in it, where each bank owns a key?

If you take Ethereum and you remove ETH/gas, you remove proof of work, you remove decentralized computation because that's just really inefficient and you want high throughput... can you really call what you have left Ethereum?

I agree. Also, the EEA is more of an R&D coordination group than anything else. It's to see if there really is something there, and these companies have joined up their R&D departments and innovation labs to do so. They have a lot of industry pull, especially together -- so if there is something viable that comes out of it, most [North American/Asian at least] people can expect it to impact the way they do things, or the way the tools they use operate.

That doesn't make sense. Read accesses couldn't possibly be logged. You probably wouldn't want sensitive information like health records in a block chain. The risk for leaks is obvious.

Both credit cards records and health records are data where there is a single authoritative data source. You want to know who actually accessed the data, and not any sort of decentralized consensus about the matter.

Agree about the wider aspects however, but those are probably about payouts to stakes in immaterial data or zero knowledge trading of cryptographic keys rather than your health data.

This is especially true for Health Records with regards to US Health Care, as access control is heavily monitored and Hospital Employees are instructed clearly and frequently that you do not access records for anyone you are not treating, accidental access needing to be reported, and so on. Confidentiality of the patient records requires a clear system to see who accessed what, when, and from where they accessed it.

Blockchain seems like a complete mismatch for such an endeavor.

Just because a node can participate in a blockchain and cryptographically verify the chain doesn't mean the node can access the plaintext of every record in check chain.

Check out permissioned implementations like JP Morgan's Quorum.

Reply on news.ycombinator.com