Blockchain as a Composable Security Context
by jeff ploughman
"Well, my daddy left home when I was three
And he didn't leave much to ma and me
Just this ole guitar and an empty bottle of booze.
Now I don't blame him 'cause he run and hid
But the meanest thing that he ever did
Was before he left he went and named me Sue."
- Shel Silverstein
Naming things is hard because names are sticky. Remembering new names takes time. Especially if names are poorly chosen. But once remembered, names forever persist in our minds, in country songs and on the labels on racks in cold basements.
Sadly, when labelling what we think we see, we invariably omit what we don't see. And often, in a single accident of naming, we can destroy entire universes rich in unseen detail.
It could be worse, I suppose... we could render them in SNAKE_CASE and make them too grotesque to look at.
Good naming is essential for robust composability: we place labels on things and then draw arcs between labels and create new labels and voilà: new things. Humans love doing this. But, languages are variously lossy encoding protocols: Some are better than others. Math is hard, but it has a pretty good signal-to-noise ratio; 240 character tweets, while simpler, do not.
Labelling failures often subvert our encoding protocols. Or, said a different way: when we don't use words the same way, we are agreeing to disagree.
A perfect example of a set of labelling failures is blockchain. We probably should have used Satoshi's original name for it: timechain. (Or something more Valley-catchy like consensus-as-a-service, serverlessless, or nocash.)
// put the main timechain first
vector<CBlockIndex*>& vNext = mapNext[pindex];
for (int i = 0; i < vNext.size(); i++)
{
if (vNext[i]->pnext)
{
swap(vNext[0], vNext[i]);
break;
}
}
The word blockchain focused our attention far too literally on the data structure that was used to support Satoshi's ingenious mutex. This led to the emergence of a bad analogy: blockchain is a database.
What's wrong with calling Bitcoin or Ethereum databases?
Well, first off, Bitcoin and Ethereum are the shittiest databases ever. And since engineers in Silicon Valley really know databases, this mislabelling contributed to the broad dismissiveness towards crypto from the Cloud and DevOps community.
But crypto protocols are not databases.
Like many other systems, they need to store state consistently, but state is merely a snapshot of a security context.
That is, blockchain is a security context not a database.
The term security context first touched my tongue as a Windows (then J2EE) developer. Since .NET and J2EE descriptions of security context are less than awesome, I'll go with this definition of Context and simply attach the word security:
Package context defines the Context type, which carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes.
Request-scoped data is ephemeral and it is trusted only so far as it is thrown. The strength of the controls that establish the security context determine the trust-worthiness of the data.
As this data is marshalled from layer to layer, each new security context is allowed to say "bugger off" if the message is spoiled, unworthy or replaced by a higher priority request (or fee.)
A successful request means that all security contexts reached consensus on the trustworthiness of the request and its data.
More precisely:
Blockchains are asynchronous security context[s] for untrusted peers which can successfully run in a forest of malicious actors.
When a browser request comes from the internet to a corporate website, the request enters a network realm known to many as a DMZ. The DMZ sits between the public internet and private corporate infrastructure.
DMZs are composable security contexts - you can put many of them together in novel ways to compose hosting-as-a-service companies. We often use segmented networking to build security contexts. The network's value is strongly correlated to the strength of its security context, and visa-versa.
The DMZ's job is to establish a trusted boundary between the browser and the corporate network infrastructure. This trusted boundary cost millions of dollars to build and years to construct. It represents a keeper relationship with CapEx and OpEx.
Once the browser's security context is established, the message is marshalled through several more security contexts on its way towards fulfilling some transactional outcome:
The composability of security contexts at the web, app, data and some of the service tiers is quite good these days (however horribly implemented at times.) It is probably nearing the commodity stage from an evolutionary perspective - for this phase of the game.
Where composability suffers the most is in the service tier where value exchange happens. This is where stackoverflow meets the dark web of the mainframe connections to SWIFT, OTC, and other clearinghouses.
At least that is what it feels like... The construction of the security contexts for value exchange always begins with a lifetime of meetings. Meetings with lawyers, bankers, vendors, and purchasing departments. (Or not: sometimes bizdev teams start building something first; but, inevitably, sometime after the first demo, these meetings start.)
These meetings can take months to years; intermittently, construction happens.
The drudgery of it all causes us to lose sight of the fact that we are doing something very subtle and important. We are building a legally binding relationship with trusted intermediaries. This requires that we maintain our part of the bargain: the integrity of the security context between us.
Composability here is hard. The business models of value exchange are long stories in tiny print written during regulatory ceremonies in interlocking boardrooms. All security contexts within institutions demand expensive trusted setup. Those related to value exchange have requirements that have proven nearly impossible to automate. Perhaps this is by design.
Ultimately, this restricts composability. But, against all odds, composability still wants to happen.
This is not a leading argument for the adoption of cryptocurrency as a value transfer layer in enterprises. The security contexts developed for value transfer within an enterprise capture necessary legal elements that blockchain can’t yet capture.
Often, once these security contexts have been established, at much expense, blockchain often seems a shitty solution in comparison.
However, during the construction of these security contexts, countless sign-offs happen.
These sign-off processes, once iterated upon, are repackaged within companies as composable modules within corporate compliance departments. They are mostly legal soup and sauce. But they can be composed artfully, packaged, bundled and resold.
The sign-off capability is a key requirement to the establishment of any security context:
An auditable boundary is established wherein counterparties sign sets of (localized) claims that define the terms of an interchange.
You can try to deliver software in any enterprise without sign-offs but it can’t be done. And, it shouldn’t be done.
Sign-offs happen everywhere, mostly in email, and never in one place. All attempts at implementing cross-system, multi-org security contexts seem to result in big, fat balls of mud.
Thing is, without a shared security context for sign-offs, your software delivery systems are often used against each other in anger. Software delivery can be a very hostile environment.
And yet, these delivery systems form an important security context for all business systems.
Can you reason about it?
The entirety of the delivery sign-off chain in any enterprise is likely entirely opaque.
Beyond the legal infrastructure for value transfer discussed above, sign-offs happen everywhere:
These systems share no security context with regard to these sign-offs - even if you’ve managed to implement single-sign on across all these platforms.
But what if you had a composable security context that you can fit to all these systems?
What if you could have a single, trusted, public audit trail that attested to a coherent view of all the sign-offs that led to the delivery of a business system… a digital asset?
Blockchain is a highly secure, cross-domain infrastructure that you don’t have to build or operate. It can be composably trusted to prove that agreements between any parties, on any network, have been made.
Blockchain is a composable security context that can be leveraged today to build trust and transparency among all the counterparties to the software delivery process.
And, eventually, even auditors will like you.
In parting...
Especially in our digital, post-anti-trust world.
Let me explain.
What is the primary security context you will leverage to build your digital-first business? Let's say you are considering being a Facebook-based business. (God forbid if you want to compete with Facebook.)
Is Facebook's composable security context sufficient to use them as a bank (Diem/Libra)? It would certainly pose many benefits for certain businesses. But what happens when Facebook (being an emerging institution) imposes new constraints on your business in order to secure their network?
Losing a banking relationship is one thing, but losing access to your customers or business platforms is another. What if Facebook's security context attempts to extend into other institutional domains? Will this impact upstream or downstream parts of your business?
The burden of composability is one of choice: the number of trade-offs that must be accounted for. I think composability aligns with antifragility: in the face of disorder, composability yields adaptability. In fact, composable things get stronger relative to everything else around them.
Disorder, leaking through institutional cracks across the globe, is part of our daily bread. Maybe the threat model has changed? Maybe it is time to be looking at different security models? Besides, collectively, our blockchain shit has gotten pretty good: Blockchains can handle 50K TPS; blockchains collectively secure around $1T in USD tradeable assets. Blockchains are composable security contexts that can be readily tailored to many use cases.
Used this way, blockchains can offer a control set that has always been lacking from the traditional security kit: institutional blast radius protection.
That ain't nothing.
"And I came away with a different point of view.
And I think about him now and then
Every time I try and every time I win
And if I ever have a son, I think I'm gonna name him
Bill or George, anything but Sue! I still hate that name!"
- Shel Silverstein
Follows will be bits of evidence that support the notion that the composability of cryptocurrency's security context is key to maintaining the strength of the network.
To address the PoW 51% Attack Cost, the solutions posed here are:
* PoS
* Coins built on top of other networks (ERC20)
* Interchain linking
2 of these solutions leverage the composability of cryptocurrency's security context to create stronger networks.
Composability makes things antifragile with respect to security.
v0.0.3, 01/28/2021
