as I discussed previously, I am in the midst of a flurry of planning some software development. One of the core concepts I have is of isolating blockchains into parts based on a single data type. Blockchains use cryptography to keep account of who did what, by requiring a signature for every transaction.

Looking at the user account model used in Steem, I decided that this quite small database could be a good project for a very lightweight example of a blockchain system, that does not involve a ledger. That is, nobody can pay anyone with this database.

A simple authentication database

You can associate a username and a small collection of data (avatar, cover picture, location, blurbs), with a public key. Using the private key that goes with this public key, you can sign a transaction that alters any one of the fields in your account, your username, the key itself, or extra data as mentioned.

There is of course no fiduciary incentive to actually run this blockchain, however, it is a small and light application and is readily pliable towards a test network that lives inside a single computer, with a test framework that runs instances with different account private keys. Each instance then is randomly selected by a controlling terminal to be the block maker according to a traffic-based schedule (really, very unlikely such a database would get so busy that one PC could not handle most of the world's accounts amendments).

You can then test the network, and have each process producing a log that you can inspect to see how it works. You can stress test it by spewing hundreds of account registrations and amendments at it, and see how fast it can process it.

Why do this?

The outcome of implementing this software concept is that you have then in the process built many of the core components involved in a blockchain. You have the executive that regulates by consensus right of a node to make a block, according to some arbitrary, agreed schedule, rules about how frequently an account can have updates done to it, and a protocol for querying the contents of the database, and an engine that takes the blockchain log and turns it into a collection of tables with indexes.

Building more sophisticated blockchains is just about refinements from this basic core. But this particular part of a multi-chain blockchain does not need much refinement except perhaps that the executive will have other ways of defining the block schedule.

Without a reputation metric, only random selection works, and yes, that means that in its sequences the network will more resemble a Proof of Work blockchain, except for testing purposes trusting the random number generator is not a concern. There is not in this design a mechanism for devising a consensus, as I intend that to be derived from other data in related subchains (a Forum subchain with a reputation system).

We are working towards a Delegated Proof of Stake multi-chain system, and to that end, once we have a Ledger and a Forum built, we can devise ways for users to generate the schedule for us by how they get along with each other.

From little things, big things grow

So it's a good target for a step-by-step process in building a theory of the practice of blockchain building. After all, sooner or later this moves from tinkering and becomes a type of engineering, once the general laws of operation are discovered.

Currently on the internet, there is a lot of sites implementing Open ID. This is basically a way of chaining other accounts to central accounts - in your, google, for example, account, you prove control by logging in, and then google tells the third party site that you validly logged in and indicated that you wanted google to tell blabla.com that session xyz at as requested has been identified with google account [email protected].

Alone, this little blockchain, which could be run on even probably 5 year old smart phones, would replace the need for this kind of authentication. It is basically like a peer to peer version of the PGP keyservers. It could replace authentication on the whole internet tomorrow if enough people realised that it ends all the mystery about the security of websites login systems.

Assuming that there is some method for defining a sequence by which nodes get the right to produce a block during a given time period.

PKI is the strongest authentication

When I first entered the Blockchain business, I had a fairly solid grounding in PKI cryptography, and the #bitcoin chatroom at freenode had an authentication bot that could use a signature from a bitcoin wallet address.

From a security perspective, it is the proper and perfect solution for identification. There is refinements you can make, like for example revocation certificates, which can be stored cold and used in case of account compromise, to invalidate and allow the record of the public key of the account to be changed to a new one.

You could also add delegation accounts to the database so that some number of other users can be designated who if a minimum are signing, the account can be rekeyed.

Before you even get to putting a ledger together, there is a lot of neat features you can build out of just an account database.

I will be building a small system like the one I have described over the next month or two, I will keep you up to date with it.

---

We can't stop here! This is Whale country!

Written with StackEdit.