Oleg Andreev: posts tagged blockchain

Blockchain business is like Formula One

Wed, 01 May 2024 14:46:33 +0000

Building apps on a blockchain is very much like the top-tier racing sport, F1. And it’s not about speed, performance or running in circles.

You see, F1 is a technical sport between some of the best engineers on the planet, and the smartest one wins the trophies. In F1, like in real life, there is a stack of technical regulations saying what you can and cannot do. If you break the regulations — you are disqualified. If you meet the regulations — try hard to reach the fourth, third, or maybe even a second place.

But in order to win your job is to find the gap — the one where the regulations mean one thing, but actually say a different one. That’s where the true geniuses figure out extra power and downforce to be added to otherwise excellent engineering expected from everyone in the paddock.

Blockchains and Fintech are somewhat like this. You don’t want to break the regulations, but you also don’t want to make a complicit product — blockchain part adds more overhead and instability to whatever traditional piece of software you are doing. Blockchain products are used in the middle area: where people need to break away from corrupt status quo imposed by old order, achieve personal freedom and take personal responsibility. All while using it wisely and not get disqualified.

In F1 only the top of the top need to find the gap. In blockchain everyone has to play this game to stay afloat. Airdrops instead of ICOs. NFTs instead of securities. Self-custody apps instead of banks. Zero-knowledge protocols over cloud computing.

You don’t disrupt the world head-on. You work around the obstacles by building a better way.

What is blockchain

Fri, 09 Feb 2018 05:19:38 +0000

Blockchain is a data structure for proving that certain events happened in a specific order.

Blockchain consists of a chain of timestamped blocks of events. Events are often called transactions.

Why timestamps? To not only order events relatively, but also pin them to the real time as it’s way more useful and in some cases necessary to make plain ordering work (e.g in Bitcoin to readjust difficulty).

Why chains? To cryptographically link past events to the current events, preserving their order under the latest timestamp.

Why blocks? Because it is relatively expensive to timestamp an event, so almost every blockchain protocol groups multiple events in a single block that gets timestamped.

Why timestamps are expensive? It takes time to reach an agreement in a distributed system. The more distributed and less well-connected the system is, the longer it takes.

What blockchain is not

Blockchain is not a “shared” or any other kind of database, blockchain is only a proof. Blockchain is typically used as a mechanism to update one’s database. The illusion of a shared database is created by multiple computers updating their databases using the same blockchain, and arriving to the same contents. Usually only a specific slice of such databases is replicated (for instance, in Bitcoin it is the set of all unspent coins), while the rest of the data is more user-specific or even private (account names, transaction annotations etc).

Blockchain is not a product in itself. Blockchain is a cryptographic proof and as such works only within specific assumptions. For instance, Bitcoin proves that a certain amount has changed hands under assumption that it is prohibitively expensive to double-spend (or reverse) that transfer and that the network is well-connected in order to detect such attempts early. Likewise, commercial/federated blockchain network assumes that the operators protect their infrastructure well from abuse and do not fork the chain. Blockchain is only a component in a larger integrated system.

Blockchain is not a transport mechanism. Transport mechanisms are necessary for delivery and replication of blockchains. Blockchain is not where “money flows”, it’s a place where money already moved and we have a proof of it.

Blockchain is not a “distributed system” in a traditional sense. Most distributed systems distribute load. Blockchains distribute vulnerability. For example, Bittorrent network and distributed/sharded databases distribute traffic and processing costs so that any single node does not have to service all requests. In a blockchain network nodes replicate and verify the same information in order to minimize vulnerability to any single node or entity.

On blockchain scalability

Traditional distributed systems are designed to scale the computational throughput, blockchains are designed to scale social interactions. Bitcoin nodes re-verify all same data and miners burn unforgivable amounts of electricity, but in return people in random jurisdictions can transact directly without numerous intermediaries and associated trust issues. As a result, the measurable costs in terms of money and time are significantly lowered and immeasurable _business opportunities_ are unlocked when more transactions become cost-effective at all.

Assets is the new cryptographic primitive

Tue, 28 Mar 2017 08:00:00 +0000

Computer science and applied cryptography in particular, has a hierarchy of building blocks, where higher-order blocks are composed of lower-order blocks.

Roughly, the hierarchy looks like this:

Charge and current in electric circuits
Bits
Bytes & words
Data structures
Permutations: block ciphers, hash functions
Self-authenticated data structures (e. g. hash-trees)
Symmetric encryption and authentication
Public key cryptography: digital signatures, shared secrets, asymmetric encryption.
Certificates and chains of trust (e. g. X.509, PGP web of trust)
Timestamped append-only logs (e. g. Certificate Transparency)

Blockchain protocols are made of these building blocks in order to offer a new kind of a building block: the digital asset.

Digital assets simplify and expand some schemes that struggle with lower-level primitives such as digital signatures and certificates.

In money: digital assets are bearer instruments that can be exchanged between parties that do not trust each other, while signatures only facilitate point-to-point exchange between trusting parties.

In supply chains: digital assets represent certificates of acceptance enabling end-to-end security for each participant in the supply chain, automating provenance and improving security of payments. E. g. a payment can be locked by condition that a particular set of certificates are produced, instead of deferring it to a third party escrow, increasing the surface of vulnerability.

In consumer payments: digital assets are used to represent not only payment instruments (cash, rewards, loyalty points), but also receipts and sometimes products themselves (tickets and prepaid cards).

In things: digital assets represent access tokens to devices running tamper-resistant computers that can be efficiently delegated, used as a collateral, bought and sold. E. g. lockboxes, vending machines and cars.

What about smart contracts? Aren’t those the next higher-order primitive? Not quite. Smart contracts use formal language to describe context-specific policy, so their impact depends on that context. Smart contracts inside a public key infrastructure (e. g. certificates) enable more sophisticated signing rules, but only within limitations and assumptions of such infrastructure. Smart contracts that control digital assets take advantage of their bearer instrument nature secured by entire blockchain network that acts as very slow and very secure computer. Smart contracts are important, but play a supportive role in systems built on top of digital assets.

Whenever you wonder how could a blockchain protocol help with a given problem, reframe the question in terms of digital assets. If there is something that can be defined as a digitally transferrable thing and benefit from automation and improved security of such transfers, then you have a reason to consider blockchain as part of your design. If not, then blockchain is probably not what you need: it would be either irrelevant (e. g. health records on blockchain) or grossly inefficient (e. g. arbitrary computation environment).

Originally published on March 28, 2017