I dig into too much in the way of coding, I feel that I should give a description of how the account database I am working on first fits into a larger fabric in my total design.

So, first, I will describe the elements of the system starting from the core 5 Subchains and then the ones that will come after it to implement further functions.

Components of the Agora Blockchain Matrix

General Considerations

The Agora Blockchain Matrix does not use Proof of Work, but rather, a Delegated Proof of Stake system like Steem, for regulating both block and new token production. Block schedules are created in a network consensus through analysis of chains and their relations between accounts, and new tokens are issued to/by the Witness who is making a block, and the distribution of this as well as a payment to the witness is included in the total.

So there is no "mining" in Agora. The network just agrees how much new tokens can be created, and each subchain has rules that determine how they get distributed. The selection of a block producer is generated by an analysis of a definite block of data found in the relevant Subchain, combined with a voting system that also determines who gets to make blocks.

The decision is not arbitrary, it is based on this data, and any valid node in the network will create the same schedule based on this data by the rules that implement it, which also include monitoring the traffic of the network for forking schedules to make more blocks at once - that is, I am not 100% certain yet whether blocks even have to be fixed size at all - but there is a limit of processing and network capacity on any given node that gives you a ceiling of possible numbers of transactions that can be packed in a block during the schedule timeslot.

The network can see that this overload is occurring because transactions that are posted before the end of the slot are not in the new block (overflow), and when the executive starts noticing this it will add a track to the schedule so two witnesses make blocks at the same time.

Also, each individual Subchain should be designed to be fairly narrow in its scope, to avoid the tangle of many data types in one blockchain. Each different Subchain produces its own blocks, and they are integrated by reference logic in the same way as a Relational Database.

The 5 Core Subchains

The Executive Subchain is the business logic. Every subchain has one both as the network protocol controller linking Witness nodes, and an executive unit that governs the specific chain in how it operates. The Executive is in charge of collaboratively generating a system-wide consensus based on data in the blockchains, for advertising the availability of a witness, and who owns it (this is a regular broadcast that prevents giving a schedule slot to a dead node, the timeout is the minimum amount blocks between which a node can be scheduled), it keeps therefore a Bitmessage-like transient database that has

• the IP address,
• Witness type (Subchain),
• and the expiry time of their availability announcement

As for the individual subchains, they have a submodule that governs the rules for making blocks, what kinds of transactions the subchain can record, their format, and the data that they must include that comes from other subchains (such as the accounts subchain which stores the public keys to verify signatures from accounts in transactions).

The Account Subchain is the project I previously mentioned, it is simply a directory that links usernames to public keys, with a free-form field for name-value pairs, like the JSON metadata in Steem accounts.

The Ledger Subchain is of course the currency system. It includes the data types of:

• consensus issued new tokens (each witness in a schedule generates a token which is divided up according to the rules and it pays out to each account that according to the network consensus says they should be, including a payment that goes to themselves for broadcasting the block - if they miss it, they miss their pay),
• 'burning' a token - where the user throws the token away by a revocation without making change,
• the change process, where the token is revoked and equal multiple new tokens are issued to the equal value,
• the transactions can be future-dated,
• can require multiple signatures to complete the transaction, which as from the previous, can be made possible only at a specified future time.

The Forum Subchain is exactly the same in principle as the Steem forum. It contains the logic to control a database that consists of posts, comments, votes, and flags.

Through processing the vote counts on one hand you generate the distribution for a pool of rewards for votes, but the votes and flags also generate a reputation score. The only difference in Agora is that the reputations decay, to model the influence of inactivity on people forgetting about someone.

This reputation score is used by the Executive to generate the block making schedule rankings. Witnesses for each blockchain are given the right to make blocks in proportion with their distance from the top of the chain of available witnesses.

There is no separate metric for deciding witness rankings because the number of upvotes over time against a decaying baseline will provide sufficient evidence of the trust of users in the witnesses, and requiring separate voting will exclude many users who don't understand it, when they are producing data that shows their esteem of an account holder in a general sense.

The Code Subchain is my own personal unique idea, basically it is an implementation of a concurrent versioning system like Git or others. The code subchain is where Agora developers can propose new code, new witness types, bug fixes, and documentation.

The code subchain maintains a current state of the codebase, and the witnesses automatically download and generate it when the consensus agrees that code should go live, and switch to it according to the agreed schedule so that the network stays consistent. The structure of the data is a tree, and allows multiple side-branches that are not yet integrated, as well as total forks that may relate to a bigger experiment in developing.

Because it is not complicated to allow multiple parent trees for the versioning system, it can also be used for managing other code for other programs not just the Agora Blockchain Matrix itself. Mostly these would naturally be applications that interact with the blockchain in some way, but really there is no limit to what this could be. It also would not be difficult if the repository got too big, to break it down into namespaces and fork the chains.

This particular idea is based on the principles of the Forum system, applied to the governance of codebase. With the Code Subchain, Agora essentially becomes a self-governing and self-hosting open source software project, making development open and completely transparent.

The Secondary Subchains

These 5 previous chains represents the minimum core for the system to completely govern itself. But there is many distributed data applications that don't quite fit into the definition of 'blockchain' and the Executive Subchain is one like this. The possibilities for Subchains are practically unlimited, but I will just describe the ones that I can think of that would be useful to augment the core Matrix.

The Data Storage Subchain is more or less like the blockchain regulated file storage systems like Maidsafe and Storj and others. The actual chain itself is a record of rental contracts for storage of data between one account holder and another. These subchains bind through associations to the Accounts and Ledger Subchains, to certify payments and manage expiry and the like.

It is intended that eventually this becomes implemented as a virtual file system, that interfaces to create a user's personal filesystem. Data stored can be either stored unencrypted, and available for any client to synchronise and use (in this way like a Bittorrent with trackers integrated with it), as well as encrypted data, which can be stored in whole pieces, or using Secret Shares, All or Nothing Transforms distributed randomly over multiple Data Storage nodes.

The owner of data is not recorded by the hosts of the data, and the index key that locates it is only known to be associated with the users personal filesystem through the user's filesystem index keychain.

Streaming media is a function that should also be available from the Data Storage Subchain. A user can request to stream from a file, and multiple nodes can feed the data down to the user, who can also seek through the file. The streaming function is connected with the download function, just with seeking added, which is automatically used for resume and fragmentary downloads from specific hosts.

The Routing Subchain is essentially an implementation of a Tor-like relay network system, but it has a broader scope in its use cases. It can be used in-band with access points and network connections, it can keep account of up and down traffic between peering/WAN links.

The use of this subchain for Tor-like relay routing is built into route generation modules in the clients. The traffic pattern requested by the user is entirely arbitrary. A Router can simply be used as a proxy, as in the case of an access point, or it can have packets wrapped in multiple layers containing destination and payment data inside each layer and only the last node sees the final payload and destination, as well as the possibility of a routing module that breaks a message into several parts using Secret Shares and All or Nothing Transforms to allow a potentially dancing fan-out-converge path that - well, in my theory, allows an interactive, but anonymised connection.

I have not fully designed the payment scheme that allows opacity between payments for traffic and their provision for uninvolved parties. It will be something to do with vouchers, zero knowledge proofs and I am not sure what else yet. The point though is that this Subchain will be profitable to run, and it will provide whatever level of antisurveillance defense that a user wants, as well as enabling hotspots you can directly pay for when connecting to it, removing the need for captive portals or other irritating web-based or other more complicated login access systems like Radius and such.

The Messaging Subchains are a system for relaying messages in both the longer and shorter format, like Email and Instant Messaging. It will work like Bitmessage but without a proof of work. Instead, like all the other blockchains, there is a bandwidth limit on accounts. In the Ledger, for example, an account can only make one transaction per block, more will go into a backlog for the next time this account is allowed to post to a new block.

To agorise this messaging system, each message has to include a postage payment. These payments are distributed to the messaging blockchain as a whole based on posts of proof of relaying a message. The sender is identified, but the receiver isn't necessarily. The blocks are bounced around the entire network and who picks it up cannot be determined.

This is one blockchain, like the Accounts Subchain, that will run in some degree of a full capacity. Because the messages are expiring, nodes can run only when the user wants them to. Whether a user wants to also relay the message blocks or not, is up to the user also, but if they do, they get paid some amount by cosigning a message block with the recipient other node, which proves the first signer send the same message to the second signer.

The messages can be encrypted, or not, at the discretion of the user posting the message. Open forums are not encrypted, and encrypted messages that have more than one recipient, they can either be encrypted to a shared key (like a keyword in an IRC chatroom) or the group can agree to broadcast their messages directly to each other node with the encryption for only that user.

The Messaging Subchain will actually have two chains, the low latency short message for instant messaging, and a high latency, larger message, which has a longer delay between new broadcasts. The rate limiting will work the same way as with all the chains, each account can originate only so many messages in some number of cycles of the chain.

The same scheme that is used to determine witnesses in the whole network also is used to route the traffic to the faster, well maintained witness nodes, which ensures that messages rapidly move towards their destination.

The Digital Estates Subchain is probably the most speculative, into-the-future subchain I have in mind. This subchain keeps a record of property claims. It can range from real estate to toothbrushes.

The Digital Estate also has to have a system of automatically calculating succession of title, and some kind of 'dead man switch' that activates when the account ceases activity for an extended time and the designated heirs then can agree to take the Estate into custody and commence the distribution process.

Some parts of the estate are not visible to the general public, but encrypted so as to be only available to privileged parties, such as lawyers and insurance agents and the like. Some parts are open record, like real estate or large movable property.

Conclusion

Particularly in the area of anonymised payment methods, I am as yet not completely finished with building the concepts for some of the Subchains, but I think that I have enough to go on with.

I just wanted to elaborate the complete concept since anyone who has been following me for a while, may have read some of my blockchain related posts and my ancient Agora post from way back in September or so, might be curious to know my bigger picture, related to the small picture discussed in the previous post:

https://steemit.com/blockchain/@l0k1/a-simple-blockchain-project-a-user-account-database

Now, back to the coding...

---

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

Written with StackEdit.