A blockchain is a digital and distributed ledger of transactions, recorded and replicated in real time across a network of computers or nodes (figure 1). Every transaction must be cryptographically validated via a consensus mechanism executed by the nodes before being permanently added as a new “block” at the end of the “chain.” There is no need for a central authority to approve the transaction, which is why blockchain is sometimes referred to as a peer-to-peer trustless mechanism.
I see this kind of explanation a lot. It's misleading at best. A block chain is most definitely not a ledger, as is claimed by too many sources to count.
A block chain is a tool allowing a group of users to produce a single, unique transaction log.
To this end, transactions are grouped into blocks. A block references two pieces of information: (1) its ordered list of transactions; and (2) its parent block. Two or more blocks may claim the same block as a parent. Therefore, a collection of blocks can be assembled into a tree with one or more children pointing to a parent.
Each user maintains its own copy of the tree. All paths through the tree are followed and scored. The path with the highest score is designated as the active chain.
The active chain is what many people think of when they use the term "Blockchain."
However, the structure of this chain is mostly boring and unremarkable. The most interesting thing about it are transactions. Like blocks, transactions link together. Additionally, transactions run programs that induce global state changes.
The secret sauce of "Blockchain" boils down to incentivizing each user to choose the same active chain in an adversarial environment. The best-tested procedure uses "proof-of-work."
If the relative order of events plays an important part in what you're trying to do, and you operate in an adversarial environment, then a block chain might help.
Otherwise, there's not much a block chain can do for you.
Journals and ledgers are where business transactions are recorded in an accounting system. In essence, detail-level information for individual transactions is stored in one of several possible journals, while the information in the journals is then summarized and transferred (or posted) to a ledger. The posting process may take place quite frequently, or could be as infrequent as the end of each reporting period. The information in the ledger is the highest level of information aggregation, from which trial balances and financial statements are produced.
A ledger can be created from a journal (transaction log), but then again, many other kinds of things can be created from a transaction log (e.g., the "World Computer" idea for Ethereum).
Why is the distinction between "ledger" and "transaction log" important? Are there technical definitions for the terms in this context that make the terms not interchangeable?
I believe a ledger is the account balances that are computed from a transaction log. So a block on the Bitcoin network is a collection of transactions, whereas a block on the Stellar network is a ledger of the account balances for all "accounts" on the Stellar network.
Each user maintains its own copy of the tree. All paths through the tree are followed and scored. The path with the highest score is designated as the active chain.
The active chain is what many people think of when they use the term "Blockchain."
This is where many people falter when thinking about blockchain. When you tell them that their esoteric blockchain needs to ensure lowest possible latency between peers (nodes), they blank out. They had never heard of the terms fork or the highest amount of work (at least if the chain is secured via PoW).
Blockchain is very applicable to industries where middlemen extract large value by being intermediaries between competing parties.
As an example, in telecom there is the issue of settlement. Every phone call generates a Call Data Record (CDR) that has information about who called who, call length, etc. This is critical because every telco negotiates individual rates for voice, SMS, data roaming, etc. between every other carrier on earth (although often you negotiate with one company that provides a package rate for multiple telcos). Your "unlimited" plan obfuscates the fact that how you use your plan, what carriers the people you call are on, where you use data, reflect different levels of profitability for you as a customer.
Large companies like Amdocs[0] make billions of dollars handling settlement for telcos. Every month, a carrier has to "settle" all of their CDR's with every other carrier. Issues get sorted out because CDR's never match perfectly, and then carriers pay each other to balance out based on their contractual obligations.
A blockchain solution that all telcos agreed on would guarantee data correctness (CDR's all look alike), allow instant settlement and payment (settlement happens once a month), and eliminate the middlemen like Amdocs, Synchronoss, etc. in regards to settlement.
Obviously this is a tough problem to crack, and you'd need to get the telcos on board, but I am explaining this as an example where blockchain could provide real value.
Indeed, Maersk, the largest shipping conglomerate, is going to release a blockchain solution to move the international shipping industry away from paper and to a unified system.[1] Maersk is in a unique position to do this because they are the largest player, and most other companies just follow what they do, but I mention this as an example where blockchain can help competing companies interact more efficiently.
However, I think maybe you're missing one thing that is being proposed as a real thing - and that is, that blockchain has become like a distributed database - I mean, there are people proposing that they can be considered as the same kind of technology, or blockchain tech can be seen as an evolution supporting database technology.
I am still on the fence if I completely believe it, which is probably why I won't get rich building blockchain-based database technology or implementing it. But I think it is a valid consideration and we as technologists should look into what this model (blockchain as a kind of database technology) really represents.
It's another arrow in the architect's quiver, perhaps.
The comment you replied to mentioned that "Large companies ... make billions of dollars handling [databases] for $companies." Central databases have become excuses to erect toll booths that blockchain may eliminate.
Because $company is only one of a number of competitors and none of them is going to let one of them handle the pot.
And because there's distribution but also only a small number of semi-trusted peers, a "blockchain" would be efficient as it wouldn't have to be a proof of work, it would only need to be a signed "public" ledger (public in the sense that all companies can access and add to it). Don't think bitcoin, think a git repo with a bunch of committer signing all their commits.
If you don't trust your business partner, don't do business with them. If there are problems, contracts and courts decide what to do. There is no need for blockchain.
Who determines if competing companies are entering authentic data into the communal blockchain? How do you address a consensus attack in an aggressively competitive industry with relatively few players?
Immutable garbage is still garbage.
Databases are perfectly compatible with any variety of authentication layers.
You are describing a Master Data Management(MDM) system. Also referred to as "single source of truth" in a data oriented system. The data in a MDM is homogeneous. The most important requisite for MDM's effectiveness that every downstream system needs to get data from MDM. No system should generate it's own data.
While those are general rule in practice, it is a difficult task to pull off. The problem is not technical but rather due to people. There are tons of department in a company. And every time an input is made things change a little. It's due to human mistakes, software restrictions and lot more.
I haven't worked in teleco but here's an example on what goes wrong when data is recorded. Marketing will send out flyers to say 100 people. One of them is named ABC XYZ. This person is interested in a phone line from say AT&T.
When sales of AT&T take this up due to some problem, the name is recorded as ABC-XYZ ie with a hyphen. Now this data is human readable but doesn't make sense to a computer. So, when it comes to tallying up marketing and sales it doesn't work.
Now things get worse when a connection has been sold, the address field in sales might be smaller compared to a full fledged customer system. So, sales says address is "XYZ Street" whereas customer system says "SSS Boulervad, XYZ Street". And then this snowballs further.
To resolve this many companies try to implement a UCM - Unified Customer Management systems, a branch of MDM. But then there are people's ego, money considerations etc come in the way. So companies don't bother with it and go with settlement vendors.
Now, this is a similar situation when it comes to CDR. Different equipment means different sets of data, that's why they need a settlement company.
So, the problem is not a simple - middlemen eating money. There are lot of things going on.
Typically a conflict-resolution mechanism will be built into the consensus mechanism, with the rules set by the peers.
But there will always be transparency (even the bad CDRs will be logged) and accountability (you know who said what, so the incentive for fraud is significantly decreased.)
A key element of blockchain is the associated business logic (smart contracts). You need an immutable ledger and you need agreed upon business logic.
You have your choice of consensus algorithms. Most of the time when people say blockchain, they mean the public networks like bitcoin or ethereum. But if you move to a private, permissioned network model, you can use consensus algorithms that don’t need mining and have very high transaction speeds. This is the approach taken by IBM Blockchain (via the Linux Foundation’s open source hyperledger fabric project) and a few others.
So eg. if telco A says a call was 8 minutes long and telco B says it was 15 minutes - what kind of smart contract / business logic decides how long the call was?
Resolving these issues can happen in several ways.
Since all participants are operating with the same data store, you can flag these conflicts in real time. You might even have individual transactions to mark start and end times, such that conflicts like this become impossible.
You might escalate to human resolution. IBM Global Finance implemented a blockchain system for thousands of its business partners in order to help resolve invoicing and payment issues. By having a trusted single source of truth, the dispute resolution process was dramatically accelerated. I don’t recall the exact numbers, but they went from something like 90 days average resolution time to just 1-3 days. This resulted in reducing working capital needs by about ~$100m, thus saving a few million dollars per year just in interest charges.
I can see the benefit of real time operation, and I can see the benefit of using a single, standardized invoicing / payment system. I don't understand why you need a blockchain for any of that.
The database is distributed among independent nodes.
Each participant has their own copy of the immutable ledger and world state.
Entries are cryptographically signed.
All interactions run through smart contracts (you can’t just insert/update).
You can form channels to engage in private transactions between a subset of the network, without divulging the existence of the transaction to the full network.
That's not really a hard problem though, .e.g. git and github; any changes made on the host are easily and immediately detectable and verifiable, no block chain necessary.
So I am assuming there is no proof of work involved in this system, correct? If so then it sort of escapes the normal criticisms of blockchain tech (extremely slow and expensive to run)
Also, let me know when we can fire our ops (finanace) and make billions more. Hope you guys appreciate how huge this would be, billions are spent daily to recon trades and positions. You mean to tell me some guy already figured it all out and all we have to do is write a wee bit of code.
Next we are going to get the Hasidic Jews on 5th ave to start using spreadsheets instead of little notebooks so they can price fix diamonds and settings faster.
> In fact, it can be considered one of the biggest technology breakthroughs in recent history, similar to the advent of the Internet in the early 1990s.
If this were the case, wouldn't we see the technology in the wild more? That seems like a bold claim for something that is still being vetted and explored.
I certainly see value in blockchain but the applications that are using it today don't excite me. The hype puts me off but I am hoping to see it bloom into other areas of software that aren't ICOs or proof of concepts.
Technologies that are actually useful tend to be aggressively adopted by military, academia, industry. Internet and IC engine were.
On the contrary, blockchain finds its activism among SQL-illiterate people, and certainly not the aforementioned groups. Mind that we're already a decade in.
The two parties either agree, or they don't. Full stop. Blockchain, or any buzzword technology, doesn't solve this eternal problem.
Third parties have historically been pretty good at sussing out consensus from the two. Judicial systems, market exchanges, etc.
When you pay a middleman, you are literally paying for Trust-as-a-Service, among other things (brokerage, etc).
Blockchain also costs money to build and maintain as a service, but it's probably the fact that the enormous cost is socialized that makes it an easy pill for many to swallow.
Who maintains the source of truth for this record of agreement? If it is one entity, that's the unaccountable middleman. Blockchain is not right for every environment, but there are industries where the middlemen are taking more than the equivalent of every party maintaining a blockchain team.
> With a SQL database, how do you achieve consensus on a proposed transaction without a middleman taking an arbitrary cut of the proceeds?
Um, there is still a middleman taking a cut with Satoshi's Glorious Blockchain. It's called transaction fees and they go to the miners who piss away small countries worth of electricity in order to validate a pathetically small number of transactions. You didn't think proof of work was free, right?
All consensus does in bitcoin is determine whether a transaction is possible or impossible (avoid double spends).
With a SQL database, this is not an issue because SQL transactions can have constraints preventing said double spend.That is to say, the SQL database can take a lock on the row and ensure no other concurrent transaction modifies it in parallel.
Consensus solves a problem that only exists in a decentralized system.
Since SQL databases are centralized, that problem doesn't exist.
Even for multi-master / distributed SQL variants, there's typically a way to wait for a write to commit across N nodes before going on, which solves the problem much more easily.
Not to mention that the industries that could be most transformed by adopting blockchains -- banking being the obvious one -- are among the most slow-moving and change-averse.
I find this to be less of a whitepaper and more of an opinion piece. For e.g.
"For example, two business parties transacting would not need to maintain their own record of the transaction and would use the blockchain as a single source of truth instead."
Ummmmmm...isn't the whole idea of blockchain that we all have a copy (our version of the truth) and a transaction is validated by several participants or miners? That's basically how we get rid of the middlemen? The sentence is clearly trying to convey that this is somehow more efficient than a current system based on a centralized authority, but there's no actual evidence that this is true.
Blockchain might bring efficiency to an industry like shipping that currently uses a VERY inefficient system, but it's disingenuous to tell others (especially if you are trying to sell something), that it is more efficient than a well implemented centralized system.
They explain the basics of permisionless blockchains and they go on and say "Prominent blockchain consortia include Enterprise Ethereum Alliance, R3, and Hyperledger", this can confuse people since R3 and Hyperledger are quite different from a permissionless chain with mining, and the value added of such platforms without crypto-currencies is highly debatable in my opinion.
> In fact, it can be considered one of the biggest technology breakthroughs in recent history, similar to the advent of the Internet in the early 1990s.
It's the internet of shit in crypto, all over again. Come on. There's nothing like 50% of the swarm simply declaring your transactions null and void, but that's obviously how the blockchain is currently operating for some ... uh, criminal reason.
Pretty good primer for newcomers, though it seems to take it as a given that blockchains are (or to hear them say it, "blockchain is") just fully as amazing and applicable as the hype suggests, and here's what you are going to have to do when you inevitably get with the program!
Another amateur's writing about blockchain. If you want the immutability, the blockchain is not immutable, just difficult to modify. Also you only need hash signature for this purpose.
I see this kind of explanation a lot. It's misleading at best. A block chain is most definitely not a ledger, as is claimed by too many sources to count.
A block chain is a tool allowing a group of users to produce a single, unique transaction log.
To this end, transactions are grouped into blocks. A block references two pieces of information: (1) its ordered list of transactions; and (2) its parent block. Two or more blocks may claim the same block as a parent. Therefore, a collection of blocks can be assembled into a tree with one or more children pointing to a parent.
Each user maintains its own copy of the tree. All paths through the tree are followed and scored. The path with the highest score is designated as the active chain.
The active chain is what many people think of when they use the term "Blockchain."
However, the structure of this chain is mostly boring and unremarkable. The most interesting thing about it are transactions. Like blocks, transactions link together. Additionally, transactions run programs that induce global state changes.
The secret sauce of "Blockchain" boils down to incentivizing each user to choose the same active chain in an adversarial environment. The best-tested procedure uses "proof-of-work."
If the relative order of events plays an important part in what you're trying to do, and you operate in an adversarial environment, then a block chain might help.
Otherwise, there's not much a block chain can do for you.