Certified Blockchain Professional - Module 1

As previously discussed, I'm doing the Certified Blockchain Professional course. It is self-directed learning, so I'm going through it at my own pace. In order to consolidate my learning, and help organise my thoughts, I'm blogging about my reflections on each module.

These are mostly notes to myself - but I hope if you find something interesting (or incorrect) that you'll leave a comment.

Module 1 is huge. It is also fairly light on details.

This means that there is no central controller in the network, and all participants talk to each other directly. This property allows for cash transactions to be exchanged directly among the peers without a third-party involvement, such as by a bank.

This is not quite correct. The ledger itself is a centralised third-party. Other people won't recognise your transaction until it has occurred on chain.

It later goes on to say:

the most critical attribute of a blockchain is that it is updateable only via consensus. This is what gives it the power of decentralization. In this scenario, no central authority is in control of updating the ledger. Instead, any update made to the blockchain is validated against strict criteria defined by the blockchain protocol and added to the blockchain only after a consensus has been reached among all participating peers/nodes on the network.

So every other node is a 3rd party? Except in the most basic networks (two people directly connected) there will always be 3rd parties - even if it's only a hardware router. The ledger may be distributed but it is identical. That's what makes it centralised. There is only one version of the truth.

Centralized systems are conventional (client-server) IT systems in which there is a single authority that controls the system, and who is solely in charge of all operations on the system. All users of a centralized system are dependent on a single source of service. The majority of online service providers including Google, Amazon, eBay, Apple's App Store, and others use this conventional model for delivering services.

I think I understand what they're saying here. Google controls the Google services. And the only route in to Google is via https://google.com/ - except... that's not really how it works under the hood. The DNS is a decentralised system and can route users to any one of thousands of Google's CDNs. Internally, Google isn't one big server and a single link out to the real world. It is highly decentralised and distributed. And that's before we get on to the different Google legal entities (.uk, .de, .es, etc) and the different Google products. True, you have to be part of Google to launch something as Google - but that's a desirable feature. And, yes, Google's products can have downtime. But that can't be solved with better distribution - unless all you want to do is serve up static assets.

Decentralized Autonomous Societies (DASs) are a concept whereby an entire society can function on a blockchain with the help of multiple, complex smart contracts[…] many services that a government commonly offers can be delivered via blockchains, such as government identity card systems, passports, and records of deeds, marriages, and births.

I don't see how this is decentralised. Only one organisation can issue birth certificates or passports. I suppose you could have a system where every hospital in the country offers birth certificates and then places them on a chain. But that doesn't require consensus voting. Having them write to a DLT may make sense - but this doesn't explain what problem it is solving - nor what problems it may cause.

Another theory is that, if a government is corrupt and central systems do not provide the satisfactory levels of trust that a society needs, then that society can start its own virtual one on a blockchain that is driven by decentralized consensus and transparency.

But… how do you stop this non-Government system from being corrupted? Or hacked? What does consensus even mean when it comes to issuing a passport?

think about an insurance contract where a claim is paid to the traveler if the flight is canceled. In the real world, this process normally takes a significant amount of time to make the claim, verify it, and pay the insurance amount to the claimant (traveler). What if this whole process were automated with cryptographically-enforced trust, transparency, and execution so that as soon as the smart contract received a feed that the flight in question has been canceled, it automatically triggers the insurance payment to the claimant?

I really like this idea. But there are three problems. First is "Chesterton's Fence" - are there good reasons for some of those delays? What level of fraud is repelled because of them? What if the claimant is the person who delayed the plane?

The second is the "Oracle Problem" - how can the chain trust data from outside its system? If I can hack the network feed of the aeroplane arrivals, then I can trigger a massive insurance payout.

Thirdly - there is nothing stopping these payments from being faster on a regular system. The UK's "Delay Repay" system for refunding late-running train services has morphed from a paper-based exercise in frustration, to a couple of clicks on a web page, and is now moving to automated repayments.

Blockchain can provide DRM functionality in such a way that it can be enforced fully.

LOL! Nope. As I wrote in Thinking of uses for BlockChains:

A music player could look at a Blockchain and only play the music for the user who had the most recent entry in the chain. When I sell my MP3 to you, I enter your signature after mine. Now I can't play that music and you can.

Which, I guess is fine. Although it relies on everyone upgrading all their hardware and software, rebuying all their media again, and hoping that every media company uses the exact same platform. And that no-one removes the DRM from their purchases.

The analogue hole defeats this idea quite handily.

There's an excellent discussion on Preimage and Second Preimage resistance. Similarly, Collision resistance and the avalanche effect was good - but would have benefited from some practical examples. The "Merkle-Damgård construction" only gets a brief mention and could have done with a more thorough explanation.

Again, only a brief mention of the "Byzantine Generals Problem". I had to look elsewhere to understand it.

Proof of work - doesn't really explain why burning resources is useful.

Similarly, Proof Of Stake

the user has invested enough in the system so that any malicious attempt by that user would outweigh the benefits of performing such an attack on the network.

OK, but how does the user "buy in" to the network in the first place? I get that a user who acts maliciously has their stake taken away from them - but it doesn't explain how staking starts.

Distributed Ledger Technology

DLTs are permissioned blockchains that are shared and used between known participants. DLTs usually serve as a shared database, with all participants known and verified. They do not have a cryptocurrency or do not require mining to secure the ledger.

DLTs don't necessarily use blocks. Again, I would like some more information on how the technology works. Is it individual nodes verifying their own transaction and then sharing them?

Proof of Burn. I've destroyed a stake, thus making the rest more valuable. Hmmm. If I destroy all the altcoins, does that make them infinitely valuable?

The "how Blockchain works" is also light on details. Sign a transaction, propagate, validate, append, reconfirmed. I get the signing and the propagation. But what does it mean to validate? I suppose checking the signature and ensuring that sufficient funds are available?

Simplification of current paradigms: The current blockchain model in many industries, such as finance or health, is somewhat disorganized. In this model, multiple entities maintain their own databases and data sharing can become very difficult due to the disparate nature of the systems. However, as a blockchain can serve as a single shared ledger among many interested parties, this can result in simplifying the model by reducing the complexity of managing the separate systems maintained by each entity.

But the same could be said of any common database schema. The problem isn't technological - it is sociological! If you could get everyone to agree on a common model, that would be great! The problem with common models - and common systems - it that they are rigid. What if one party needs to add a bespoke field to their data?

In the financial industry, especially in post-trade settlement functions, blockchain can play a vital role by enabling the quick settlement of trades.

Is this true in reality though? Most chains are notoriously slow. And, we go back to Chesterton's Fence as above - what are the advantages of doing things slowly? Do it help prevent fraud or flash-crashes? At a retail level, people can send money instantaneously to each other using traditional banks. Could a Blockchain which requires P2P validation be faster?

Cost saving: As no trusted third party or clearing house is required in the blockchain model, this can massively eliminate overhead costs in the form of the fees which are paid to such parties.

Again, this isn't true. Cryptocurrencies are full of middle-men taking overhead costs. And, again, in the UK it is free to send money between bank accounts. So what's the advantage here?

Another burning issue is counterfeit medicines; especially in developing countries … With the adaptability of blockchain in the health sector, several benefits can be realized … preventing the distribution of counterfeit medicines.

This isn't true. OK, you can stick a QR code on a box of pills, and that code can trace the origin back. But there's nothing stopping a counterfeiter copying that code and putting it on fake medicine. A user might be able to scan a code and "claim" that pack - but nothing stops people from doing that with a traditional database.

There's only a small section on challenges - literally two paragraphs. Scalability is an issue. How does technology get adopted? What happens when it fails? Privacy is the other big issue. With an immutable record of transactions, people can see what you're buying. Similarly, private data like medical records can never be erased.

But, apparently, this tech is expected to mature around 2025. We'll see!

Assignment

Terence Eden is on Mastodon

@edent

Replying to @edentAmazing. The first assignment in the Certified Blockchain Professional course is to read the Satoshi Nakamoto paper at bitcoin.org/bitcoin.pdf

It isn't available there. Why?

Because of the weird copyright court case! bitcoin.org/IL-2021-000008… pic.x.com/qsqu4kbewh

---

Terence Eden is on Mastodon

@edent

Replying to @edentThe first hit that I could find for the paper is on the U.S. Sentencing Commission website.
ussc.gov/sites/default/…
No comment!

---

What is proof of work and why it is necessary?

Use of CPU power to calculate something. That something is x where the hash h(x) starts with a specific number of zero bits. And X is the previous hash, the current transaction(s), and a nOnce. The nOnce is really what you're trying to find.

This prevents double-spending, or reversing of transactions.

What is defined by chain of digital signatures?

Each block is cryptographically signed by a node. Each block contains the hash of the previous block, which was cryptographically signed. So it is possible to walk down a chain to verify each block's signature. And to ensure that the block's content also contains a valid signature.

How can nodes stay honest?

Only accepting verifiable blocks which haven't already been spent. By not colluding with other blocks to accept or generate invalid blocks.

Where is blockchain mentioned in the paper?

It is not.

Define electronic coin

The paper describes it as a chain of digital signatures.