Richard Gendal Brown, a blockchain and distributed ledger specialist who worked on R3's Corda, writes plain explanations of banking, settlement and ledgers.
HN commenters point to his posts as clear explainers: how money moves through banks, and how distributed databases differ from distributed ledgers.
Hi everybody... Richard Brown, CTO of R3, the firm behind Corda, here.
As Mike says, we're somewhat unusual in that there are many live, successful Corda deployments around the world. Mike's comment about how Corda is blockchain-like but not, strictly speaking, a chain of blocks is at the heart of this I think. Here's what I mean:
How many 'introductory' presentations have you been to (or, worse, given) to semi-technical people, where Bitcoin and other public blockchains are 'explained' by describing the components? You probably know the sort of pitch I mean: they laboriously build up the concepts - transactions, signatures, hashes, blocks, chains of blocks, mining, etc, etc. Such presentation are usually correct. But they impart almost no intuition. It's little wonder that so many 'business people' come away from them thinking that a blockchain is some sort of mysterious and magical technology.
There's a presentation I like to give where I go the other way. I give a one-line description of the problem Bitcoin solves [1] and then I help the audience 'invent' Bitcoin for themselves from first principles. There's an old blog post of mine that gives the rough idea [2]. The point is that successful architectures solve well-stated problems. Cargo culting never works.
Where I think many corporate deployments of blockchain went wrong was that they saw the huge enthusiasm for 'blockchain tech', had a vague intuition that 'inter-firm' or 'market-level' problems were ripe to be…
The Bitcoin whitepaper [1] (which is very short, concise, and definitely worth the read) describes how the Merkle trees might be pruned (transactions could be pruned when all outputs are spent) and in fact Bitcoin 0.11 added pruning (and 0.12 added further compatibility for pruned nodes).
Vitalik Buterin (Ethereum lead) also posted a description of how Ethereum will implement State Tree Pruning [2].
These are short/medium-term scaling solutions.
Many people are pushing sidechain [3] / child-chains [4] as longer-term ("Visa" level) solutions.
* Lightning Network [5][6] is what Blockstream and others are pushing for Bitcoin scaling.
* Raiden Network [7] is the Ethereum version, and may come out before Lightning, funnily enough.
For those interested in the topic matter, Vitalik wrote a pretty dense paper on blockchain scaling last year [8].
While sidechains will be an option, Ethereum is also pursuing on-chain scaling as well.
Sharding is scheduled for the upcoming Serenity release [9] (which also switches to Proof of Stake (Casper), another important scaling-related change). Writeup on Serenity PoC2 [10].
In general for scaling atm, processing/network latency/bandwidth for initial sync is more of a bottleneck than raw storage. By that measure, I'm actually a lot more interested in the on-chain tx-processing that Casper/PoS might bring [11].
Of course there's no requirement for a single chain to handle everything. Especially over the past few months, we've seen a few…
Richard Gendal Brown has a great post on the difference between a distributed database and a distributed ledger: https://gendal.me/2016/11/08/on-distributed-databases-and-distributed-ledgers/
The Coco team shares Richard's view that the distinguishing factor is where the trust boundary exists within the system. In the case of Coco, we assume a lack of trust among consortium participants, but we leverage the attestation and anti-tampering features of Trusted Execution Environments (TEEs) to establish trust between the enclaves: assuming that the TEEs themelves are trustworthy, the TEEs can provide cryptographic proof of the software and configuration running on each enclave. In other words, I don't trust you, but my enclave has decided it can trust your enclave based on mutual attestation exchange and mutual authentication. In other words, we've transitioned from a byzantine failure mode (adversary can replace the expected remote code with arbitrary code at will) to a crash failure mode (adversary can shut the remote enclave down at will, but not alter what runs on it).
Once there is trust between enclaves, Proof of Work seemed inefficient as a consensus mechanism, although it's certainly one choice that is available and that can be used with Coco (in this case Coco would provide governance and confidentiality, but scalability and latency would be limited by PoW). Instead we can use any one of many distributed systems techniques such as Paxos or Raft to achieve…
The content in this article about anti-spam techniques is fascinating. But the title should be edited to indicate its vintage: 2014.
Also, by the by, there is some interesting context about the author (Mike Hearn) and his recent activities that are not related to the topic of spam.
Warning: off-topic digression below.
Mike Hearn became one of the most visible Bitcoin core developers, working in that community for 5 years, until a well-publicized departure where he declared Bitcoin a failure[0].
He then joined R3CEV, a startup venture that is building a private blockchain platform for a consortium of 70 of the world's largest banks. Hearn's departure was criticized by members of the cryptocurrency community, such as Bram Cohen, who famously called his exit a "whiny ragequit" [1].
Regardless about how one feels about the internal politics of the bitcoin dev community, the R3 project is technically interesting (to me, at least) because it uses Kotlin [2], a JVM-based functional language, and also because it has some interesting design approaches that depart from the established bitcoin blockchain model [3].
I still think that private blockchain platforms have an uphill battle if they want to compete for developer attention with rapidly evolving broad-based platforms like Ethereum and Bitcoin, but the R3 Corda platform is nevertheless worth tracking.
[0] https://medium.com/@octskyward/the-resolution-of-the-bitcoin-experiment-dabb30201f7
[1]…
> there is someone at a desk with a terminal
I haven't found a single good description/explanation of how the actual operations are carried out "on the ground".
It's hard enough to find information on how the financial system works in an abstract way. It amazes me that 99.99% of the people who (also indirectly) use it, including the financial 0.1%, don't know what and "where" their shares actually are.
Maybe the exact technical nature of the system doesn't even matter, because ownership and rights are more of a legal idea, but on rare occasions the exact implementation matters.
The best explanations of parts of the financial system I have found so far:
https://gendal.me/2013/11/24/a-simple-explanation-of-how-money-moves-around-the-banking-system/
https://gendal.me/2014/01/05/a-simple-explanation-of-how-shares-move-around-the-securities-settlement-system/
I'd love to read something like this that shows what kind of hardware and software is actually being used, and which standards are at the interfaces between institutions. What physical, hardware and software requirements are actually needed to start a bank?
These seem to be the backbone of the system:
https://en.m.wikipedia.org/wiki/Systemically_important_financial_market_utility
https://en.m.wikipedia.org/wiki/Systemically_important_payment_systems
https://en.m.wikipedia.org/wiki/Systemically_important_financial_institution
No it only shows they've done their homework.
Allot of the "security" of banking processes is based on human verification often via phone, fax, printing etc. so it's not surprising that they've compromised the printing process because that would flag the transactions immediately as the process mandates for the printout to be reviewed (and usually singed, and then filed with compliance).
If you can present an all clear signal to the bank staff at all the immediate human readable interfaces no one would notice, at best the fraudulent transactions would be detected 30+ days down the line when the banks perform account consolidation.
This is a good post about how money moves around between banks https://gendal.me/2013/11/24/a-simple-explanation-of-how-money-moves-around-the-banking-system/ it doesn't go into payment/messaging systems (i.e. SWIFT) too much which is a good thing but it does explains how bank handle and settle transfers.
SWIFT is a glorified messaging service for banks, that's how it started, today allot of "out of the box" applications have been developed on it but in it's core SWIFT is just a trusted network that enabled it's members to securely transfer messages between each other, these messages often end up being used to facilitate transactions but they aren't what actually moves money around.