April 29, 2015

The Sum of All Chains - Let's Converge!

Here's a rough transcript of a recent talk I did for CoinScrum & Proof of Work's Tools for the Future (video).


I was asked to pick my own topic, and what I was really interested in were some thoughts as to where we are going with the architecture of the blockchain and so forth. Something that has come out of my thoughts is whether we can converge all the different ideas out there in identification terms. It's a thought process, it's coming bit by bit, it's really quite young in its evolution. A lot of people might call it complete crap, but here it is anyway.

The sum of all chains
let's converge...



Imagine there is a person. We can look at a picture, what else is there to say? Not a lot.

But imagine, now we've got another person. This one is Bob, who is male and blue.


What does that mean? Well what it really means is that if we've got two people, we've got some differences, and we might have to give these people names. Naming only becomes important when we've got a few things, a lot of things, which is somewhat critical in some areas.

What then is Identity about? In this context it is about the difference between these entities, Alice versus Bob. Things we can look at with any particular person include: Age, gender, male versus female. We could just do the old ontology thing and collect all this information together into a database, and that should be sufficient.


But things can be a bit tricky. Gender used to quite simple. Now it can be unknown, unstated, it can change, as a relatively new phenomena. On this random slide off the net, down there on the right, it says "I'm bi-gender, so please use they." This brave person, they've gone out on the net, they're interested in secure properties of naming via object capability systems, which is really interesting as that's what we're talking about here, and they want us to refer to them as they.

This really mucks up gender completely as we can no longer use binary assumptions. How do we deal with this? There's a trap here, a trap of over-measurement, a trap of ontology, which leads to paralysis if we're not careful.

Imagine a group of people? What happens when we get a group of people together - it can be called an incorporation, we might need a number, we might need a type. We're going to need rules and regulations, or at least someone will impose regulations over the top of us. We've got quite a lot of information to collect.

We can go further afield. In times historical, we might recall the old sea stories, where they would talk about the ships having names and the engines having names. In modern times, computers have names as do programs. Eliza is a famous old psychology program, and Hal and Skynet come from movies. When the Internet started up it seemed as if every second machine was named Gandalf.

There's lots of attributes we can collect about these things as well -- can we identify machines in the same way that we can identify people? Why not?


Let's talk about a smart contract. It's out there, it exists, it's permanent, it's got some sense of reality, so whatever we think it is -- I personally think it is a state machine with money, and there are lots of people hunting around for definitions to try and understand this -- whatever we think it is, we can measure it. We have to be able to find it, we have to be able talk to it. We can find its code, and certainly in the blockchain instantiation of the concept, it's code is everywhere, and its running. We can find its state, if it's a multistate machine, and those are the interesting ones I think.

And it probably has to have a name, because it probably needs to market itself out to the world, and you can only really do that with a name. We can collect this information.


If we can do a smart contract, what can't we do a blockchain? With a blockchain, there's certainly a location, there's a bunch of IP numbers out there, a bunch of places we can talk to. There's a lot of technology types out there, and these are important in interpreting the results that come back from it, or how to talk to them, protocols and so forth. There are lots of different types.

There's a controller, or there's probably a controller. Bitcoin for example has alertSigningKeys and dnsSeeds. Thelonious for some reasons has a smart contract at the beginning, which is interesting in and of itself.


And, blockchains have a name. Probably a bit of a surprise, there are 4 bitcoin chains. One's called "mainnet", that's the one you're used to using, then there's "testnet" and then a something net and a something-else net.

So we can have a "mainnet" can we also have "AliceNet" or "Mynet?" Yes, in theory we can. If you're in the business of doing interesting things with bitcoin, you probably want to talk to corporates, and when you go into talk to corporates, they probably turn around and say

"love the concept, but we want our own one! We want to run our own blockchain. We probably want a sidechain, or one of those variants. We want to change the parameters, we want to change it so the performance is different. We want it to go faster, or maybe slower. More security perhaps, or more space. Whatever it is, we want smart contracts rather than money, or money rather than smart contracts, or whatever."
If we're talking about contracts, they (corporates) probably want a legal environment because they do legal environments with everything else. When you walk into the building, there's a contract. If you walk onto a train platform, there's a contract, it's posted up somewhere. If you buy sweets in a shop, there's a contract. Corporates then likely want some form of contract in their blockchain.

Then there are sidechains. These become interesting because they break a lot of assumptions. The interest behind sidechains has a lot to do with multiple assets. Some people like counterparty or coloured coins are trying to issue multiple assets, and sidechains are trying to do this in a proper fashion. Which means we need to do things like separate out the genesis block out so that it starts the chain, not the currency. We need a separate genesis for the assets.

We also need chain identifiers. This is a consequence of moving value from one chain to another, it's a sidechains thing. if you're moving coins between different chains, you then have to move them back again if you want to redeem them on the original chain. They must follow the exact same path, otherwise you get a problem if two coins coming from the same base chain go by different paths and end up on the same sidechain. Something we called diamond coins.


Where is this all going? We need to make some changes. We can look at the blockchain and make a few changes. It sort of works out that if we take the bottom layer, we've got a bunch of parameters from the blockchain, these are hard coded, but they exist. They are in the blockchain software, hard coded into the source code.

So we need to get those parameters out into some form of description if we're going to have hundreds, thousands or millions of block chains. It's probably a good idea to stick a smart contract in there, who's purpose is to start off the blockchain, just for that purposes. And having talked about the legal context, when going into the corporate scenario, we probably need the legal contract -- we're talking text, legal terms and blah blah -- in there and locked in.

We also need an instantiation, we need an event to make it happen, and that is the genesis transaction. Somehow all of these need to be brought together, locked into the genesis transaction, and out the top pops an identifier. That identifier can then be used by the software in various and many ways. Such as getting the particular properties out to deal with that technology, and moving value from one chain to another.

This is a particular picture which is a slight variation that is going on with the current blockchain technology, but it can lead in to the rest of the devices we've talked about.


Let's talk about a DAO or distributed autonomous organisation. What is that - I'm not entirely sure what it is, and I don't think anyone else is either. It's a sort of corporation that doesn't have the traditional instantiation we are familiar with, it's a thing out there that does stuff, like a magic corporation.

It probably lives on a chain somewhere, so it has a location. It's probably controlled by somebody. It might be autonomous, but who would set it up for autonomous reasons, what's the purpose of that? It doesn't make a lot of sense because these things generally want to make profit so the profit needs to go somewhere. Like corporations today, we expect a controller.

It probably needs to make contracts with other DAOs, or other entities out there. Which means it needs to do some signing, which means it needs keys. Code, accounts, capital, it needs a whole bunch of stuff. And it has a name, because it has to market itself.


What am I saying here? It kind of looks a lot like the other things above.

Issuances have existed in the past, Bitcoin is not the beginning of this space. Before Bitcoin we've had the pound sterling for several hundred years as an issuance. Cyberbux was issued around 1992 as a digital currency. It was given away by David Chaum's company Digicash which issued about 750,000 of them before he was told to stop doing that.

Paypal came along as an issuance. Digigold was a gold metal based currency that I was involved with back in the early 2000s, then it was quiet for long time until along came Bitcoin.

These issuances all have things in common. They all had an issuer in some sense or other. It is possible to dispute it with Bitcoin, but Satoshi was there starting up the software, so he's essentially the issuer albeit unstated. The issuances have types of technology and types of value such as bonds and shares, etc. There is stuff about symbols to print out, as the user wants to know what it looks like on the screen. Is it GBP, BTC. What are the units, what are the subunits, how many decimal points.

We need to know how minting is done. That's hard coded into bitcoin, but it doesn't have to be, it could be in the genesis identity package, so we can tune the parameters. There needs to be a controller, as I pointed out there are some vestiges of control with bitcoin, and future chains will have more control, whereas issuances will have even more control because issuances are typically done by issuers. You want them to be in control because they're making legal claims, which brings us to terms and conditions, so we also need a legal contract.


It looks like the other things, as it has the same elements.

Where I'm coming to is that there is a list of First Class Persons in this new space that have the same set of characteristics. Humans, who do stuff, Corporations making decisions, DAOs making profits, smart contracts are making decisions based on inputs, chains are running and are persistent and supposed to be there. Issuances are supposed to serve your value-storing needs for quite some time.

Internet of things - it might seem a little funny but your fridge is sitting there with a chip in it, running, and it can do things. It could run a smart contract, it could run a blockchain, it could do anything you like, it has these attributes, it could act as a first class person.


What do these first class persons need? If we line them up on the top axis, and run the characteristics down the left axis, it turns out that we can fill out the table and find that everything needs everything, most of the time. Sure, there are some exceptions, but that's life in the IT business. For the most part they all look the same.

What do these First Class Persons do? Just quickly, they instantiate, they communicate, they name each other. Alice needs to send Bob's names to others, she needs to make claims about Bob, and send those claims onto Carol. As we're making some semblance of claim about these entities, the name has to be a decently good reference. Then there will be the normal IT stuff such as identify, share, change, blah blah.

What then is a First Class Person? They have capabilities to make decisions, are apparently intelligent in some sense or other. They have state, they are holding value, they might be holding money or shares or photos, who knows? (Coming back to a question raised in the previous talk) they have intent, which is a legally significant word.

So we're all the same -- we people are the same as smart contracts, as block chains, etc, and we should be able to make recipe that describes us. We should be able to collect all these things together and make it such that we all look the same.

Of course we're all different - the fields in the recipes will all be different, but that's what we IT people know how to do.

Although we can do this -- doing it isn't as easy as saying it. This package has to be tractable, it's got to be relatively small and powerful at the same time. It has to contain text and code at the same time which is a bit tricky. It has to be accessible and easy to implement, which probably means we don't want XML, it may mean we could do JSON, but I prefer line-based tag-equals-value because anyone can read it, nobody has to worry about it, and it's easy to write a parser.

Other things: it has to include its own PKI, it cannot really resort to an external PKI because it needs to be in control of its own destiny which means it puts its root key inside itself in a sense more familiar to the OpenPGP people than the x.509 people. And it has to be able to sign things in order to show its intent.


We need an identifier. The easy thing is to take a hash of the package that we've built up. But Zooko's Triangle which you really need to grok Zooko's Triangle to understand the space basically says that we can have an identifier that can have these attributes -- globally context free, securely collision free, human meaningful -- but you can only reach two of them with a single simple system. Hence we have to take the basic system we invent and then square the triangle to get the other attribute, but that's too much detail for this talk.

What are we seeing? We're capturing a lot of diversity and wrap it back into one arch-type. Capture the code, text, and params, make it work together and get it instantiated and then get the identifier out. The identifier is probably the easy part, although, you'll probably notice I'm skipping something here, which is what we do with that identifier once we've got it.

In a sense what we are doing is objectifying and from an OO programming sense we are all objects and we just need to create the object arch-type in order to be able to manipulate all these First Class Persons.


So what does it look like - another triangle containing a legal contract, parameters and a smart contract along the bottom. Those three elements are wrapped up and sent into a genesis transaction, into a something. That something might be a blockchain, might be a server, it might not even be what we think of as a transaction or a genesis, it looks approximately like that so I'm borrowing the buzzword.

Out of that package we get an identifier! That is what it looks like today, but I admit it looked a little different yesterday and maybe next week it'll look different again. Some people on the net are already figuring this out. CommonAccord are doing legal contracts, wrapping them up into little tech objects, with a piece of code that they call an object and they have a matching legal document that relates to it. A user goes searching through their system looking for legal clauses, pull out the ones you want, compose them into a big contract. With each little legal clause you pull out, it comes with a bit of smart code, so you end up creating the whole legal text and the whole smart code in the same process.


CommonAccord are basically doing the same thing described - wrapping together a smart contract with a legal document and then creating some form of identifier out of it when they produce their final contract.

It's out there!


How do we do this? Open problems include how to mix the code and text. Both the code and the text can be very big, derivatives contracts can run to 300 pages. Hence some of the new generation blockchain projects have figured out they need to add file store in their architecture.


We need to take the genesis concept and break it out - the genesis should start the chain not the currency, and we should start the currency using a different transaction. This is already done in some of these systems.

Then there are is the "other identity" -- I haven't covered whether this is safe, whether you know the other person is who they claim to be, whether there is any recourse, or intent, or even a person behind an identity, or what? We really don't know any more than what the tech says, and (hand wave) that's a subject for another day.

There is a conflict in that we're surfacing more and more information which is great for security as we're locking things down, but it does rather leave aside the question of Privacy? Are we ruining things for privacy? Another question for another day.

References!

Addendum

Posted by iang at April 29, 2015 07:06 AM
Comments

Great article, and very interesting read. Not a piece of crap at all, in my opinion. Now to get to the point...

Lets say there was a distributed database that stores identities (I'll reference to this as "node" from hereon), and anything that has ever been said about them at anytime, by any other identity residing on the same node. Anyone with access to this node could create identities and say anything about any other identity on the node. Also, both identities and the node itself create and mange their own personalized Webs of Trust (WoT), who'll need to be insusceptible to Sybil attacks, in order to ensure that all relevant information remains reliable at any given point in time for said node/identity.

Any identity on the node would consist of:

1.) A subset of attributes (which I'll refer to as "identifiers" from hereon).
The types of identifiers could either be a name, nickname, gender, DoB, URL to social media account, IS_UK_RESIDENT, IS_OVER_18, BTC address, etc.
There wouldn't need to be restrictions on the types nor values of these identifiers, only agreements / a protocol among trusted parties to ensure they all understand each other when they need to, so that basically any kind of identifier could be added by any identity, to any other identity on the node. These types could then contain any given value, with no restriction on it whatsoever. Examples could be: type of identifier = name, and value = Bob; type = IS_OVER_18, and value = YES; type = BTC, and value = a public Bitcoin address on the main net, etc.
Identifiers also have a private/public setting, to which I'll get back at point of smart contracts.

Both the identity and its identifiers all have their own seperate public addresses. The owner of any identity / creator of an identifier would be the only one able to prove (s)he's the creator of that identity/identifier, via ownership of a private key and corresponding signature and public address, and thereby verifies that information to be true according to him/her.

2.) The reputation tied to any identity, would be sent and received ratings.
Sent/received ratings are meant for any identity to be able to say anything about any identity at anytime. This could be either "Alice is a terrific barber", "Bob is the worst car salesman I've ever met!", or "DID_REPAY_LOAN_ON_TIME".
Also, a score could be added to the rating. How scores are measured will be decided upon by the owner of the node, so that it could be either between -10 and +10, between 0 and +100, or between 3 thumbs down and 3 thumbs up.

3.) The identity (the node is an identity too for that matter) has its own personalized WoT, according to the whitelisting principle. This should guard any identity's verified relevant information on the node from the irrelevant information, and should thus solve the Sybil attack.

Only identifiers that have been verified by an identity will be added to the identity's WoT, along with the identifier's associated identity. This way, an identity within Alice's WoT could contain different identifiers than the same identity in Bob's WoT, since Alice might verifiy identifiers A, B, and C, while Bob might verify identifiers B, C, and F.
This type of a mechanism will make the trustworthiness of the WoT as good as the least trustworthy identity within it, based on which identifiers/identities have been verified by the owner of the WoT itself.

By applying this technique, identities could verify identifiers of any identity, or add identifiers to identities and thereby verify these identifiers, which would automatically add these verified identifiers and their associated identity to their WoT. This means that all identifiers that have not been verified will be seen as irrelevant and hold no influence over the identity's WoT in any way.

--------

Now to address the issues you've posed in your article above:

Gender issue: Say Alice has added an identifier to her identity (type = gender, value = female), to then turn bi-gender. She could now simply down-vote the old gender identifier, and add a new one (type = gender, value = bi-gender).
Everyone who has verified Alice's identity by verifying her gender will now see that Alice has said that the old identifier is longer true, according to herself, and can then see that she claims to be bi-gender from this point on. Since these parties seem to trust Alice, she's in their WoT after all, they can assume to a high degree of certainty that this information is true.

A group of people: Basically another identity. The person who controls and manages this identity could add/verify that certain other identities belong to this identity (type = member, value = public address of the identity).

Machines: They could have their own public addresses, corresponding private keys, and personalized WoTs. This way, any machine could have their own identity, and automatically decide whom to trust. Maybe the privkey could be stored in a Trusted Execution Environment or something. I don't know, I'll let the security experts figure that one out.

Smart Contracts: Here is where it gets interesting, since only the node itself won't suffice from this point on. What we now need is an ability for nodes to communicate with one another, in order to be able to exchange information among themselves, based on a set of permissions and thresholds.

For this, we'll take a slightly modified node that can act as a permission database, and filter/firewall & communication application, to interact with other (trusted) nodes.
These type of nodes also contain their own WoT, of course, which they'll use for the purpose of the permission database. The modification to this node would therefor be mostly to act as a communication application between nodes, running as a seperate node between the node that stores the identities and all the other trusted nodes. Thresholds could now be set on both sides and verified/executed. Any identifier marked as private will never be shared, not even with trusted nodes, and identifiers marked as public may be shared in accord with the permission database.
This will enable private nodes to talk with each other. So, then we would have public nodes, private nodes, and public/private (translucent?) nodes.

Locations could now be tied to public addresses, and be stored in a decentralized name services fashion. Also, this technique could enable alertSigningKeys and dnsSeeds like functions.

Blockchains have a name, so we'd just need to agree on a set of names for the types in order to solve the issue of chain identitifiers (e.g., BTC for Bitcoin mainnet, BTCtest for test, BTCalice for AliceNet, BTCmynet for Mynet, and Skynet for Skynet), for when we'd all want to be able to talk with one another, but there wouldn't be any restrictions on the types. For the values, associated to the types, we could then use the public addresses.
So if you'd like to refer to the BTC mainnet as "Namecoin" on your node, that's fine with my node. That information will then simply make no sense to my node while communicating, that's all.
This should also solve the issues corporates might have with such a system, since they can use it however they like, and it should nicely integrate within their existing production and legal environments.

I'm not sure what a DAO should look like myself neither, but the image that I get of it looks pretty cool. I'm sure the system described above here could help them in some sense, since it's inessentially nothing more than just another identity. This would give them the needed keys for signing, and the possibility for nodes/identities to verify that any statement/verification/addition has been added/verified by that identity itself.

Either the node or any identities stored on it would be First Class Persons, looking at the characteristics. It should also enable giving an identity to any device connected to the IoT (Internet of Targets).
Looking at what's needed for that, according to what you've described in your article, Alice and Bob would now be able to make any type of claims, and Carol would be able to verify any of those. Also, the IT dept. should be able to handle all of this stuff in both a user-friendly (with whitelisting? whoah!) and secure way, via the front-end. So, yes, without a trade-off between UX and security.

So, people, smart contracts, machines, religious organizations, corporates, whole countries for that matter, would be not much more than just another identity on a node. All the same and both different at the same time, so that the interpretion of Alice about Bob's identity could difer from Carol's view on who he is, according to her.

JSON seems like a good way to go about it. How about using the same JSON RPC API that the Bitcoin daemon (bitcoind) uses? To give an example, it could make the JSON of a sent verification of an identifier look something like this:

-------------

{
"hash": "AEiHP29kXaW3k5QkVNYP8gd1hrdSs7LvEauanfTzGMAa",
"data": {
"signature": {
"pubKey": "PA4oX2htY35kXuNVnvNxXHiSigfcfJJyxJntwfgx7tgisjVbuEKcb1v3V2dojuHkrRyfVAu9Yi24nFcSPEdEvLeN",
"signature": "AN1rKr3gnNf7JgmDXANoLkSN3KNMgsyJtMAYKFXdPdxAvDktfFTncCpEvi1Z1AtJ9JjxGeFhdchPcWgWkg3Mceh2KAsbpQKTP"
},
"signedData": {
"author": [
[
"url",
"https://www.facebook.com/Alice"
]
],
"recipient": [
[
"name",
"Bob"
],
[
"url",
"https://www.facebook.com/bob"
]
],
"timestamp": 1414442863,
"type": "confirm_connection"
}
},
"published": true,
"priority": 17,
"signatureDetails": {
"signerPubKey": "PA4oX2htY35kXuNVnvNxXHiSigfcfJJyxJntwfgx7tgisjVbuEKcb1v3V2dojuHkrRyfVAu9Yi24nFcSPEdEvLeN",
"signerKeyID": "1DqrzTcimQp3Ye88oHgxdU7DBTsM2TRYFj",
"signature": "AN1rKr3gnNf7JgmDXANoLkSN3KNMgsyJtMAYKFXdPdxAvDktfFTncCpEvi1Z1AtJ9JjxGeFhdchPcWgWkg3Mceh2KAsbpQKTP"
},
"authorName": "Alice",
"recipientName": "Bob",
"authorEmail": "",
"signerName": "Identi.fi",
"authorGravatar": "7e381ba0e2e40353d922f8ad49006437",
"recipientGravatar": "f31830f37a67bc0f6e0d87c9f019bb7e",
"linkToAuthor": [
"url",
"https://www.facebook.com/alice"
],
"linkToRecipient": [
"url",
"https://www.facebook.com/bob"
]
}

-------------

This way it would also include its own PKI. I'm open to suggestions concerning the line-based tag-equals-value.

This system should also square Zooko's triangle, if I'm not mistaken.

You can find the free open source (MIT licensed) proof-of-concept of the system described above here: https://github.com/identifi/identifi

I'd be more than interested for your feedback and/or questions, and to see if you're going to send us back to the drawing board. If so, no hard feelings.

Posted by: Tim Pastoor at May 3, 2015 05:02 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.