Not sure how useful this will be, but I thought I might drop this here to see how many people I can get thinking about this.
This was the layer diagram I was basing the 2.0 impmentation on. I have several additional architectural diagrams that I'd be willing to share with the development team when and if our schedules align to allow it and if they are still interested.
Notably missing from this (admittedly old) diagram are the auditing service (read: block explorer, though the two are not quite the same thing) and the dependency between the transaction queue and the ledger service. Omissions such as these are what have delayed my progress in updating the whitepaper with more correct descriptions of the architecture.
Some information on what you're seeing here:
The client layer describes client applications that help you manage (or generate) funds. There is the wallet, which facilitates generating new transactions as well as displaying balances allocated to a given private key, as well as a special type of account (where the funds are not directly spendable) that facilitates generating what could be described as PoS blocks, though the moniker is not completely accurate in the case of the component model. Also contained in the client layer is the "scribe", which performs duties similar to what you would call "mining" or PoW blocks. The scribe's job is slightly different from a miner, however. I will not get into the intricacies of how any of the components work, but its basic job is to transcribe a list of transactions along with a valid nonce into a block of a particular structure, format, and set of validating algorithm parameters (defined by the infrastructure layer).
The service directories layer manage the p2p aspects of the system and are responsible for handing data of various formats between the various services that make the network function. Consider it the business logic of the system as it manages the p2p network, is responsible for concensus, and overall gives precedence to whichever chain it deems valid (based on a set of rules defined within the infrastructure layer.) It then directs clients to the needed services based on the task that they wish to accomplish (whether it be sending money or transcribing blocks, or even simply auditing the chain).
The backend layer is responsible for maintaining the global list of pending transactions as well as the ledger itself. Pending transactions with no confirmations (ie. not yet included within a block) are managed by the transaction queue and are eventually given to a scribe to be dealt with accordingly. Once a given transaction has reached maturity, it is committed to the ledger and removed from the tx queue. This is where the ledger daemon/server handles the actual storage of the blockchain.
Given this architecture, the requirement for maintaining a copy of the ledger becomes completely optional for a given user. All wallets are thin clients by default. A ledger has no ownership of coins and a server containing nothing but a ledger has no risk of having a wallet stolen or compromised. Proof of work and proof of stake work hand in hand with a scribe to create and generate blocks which can be stored in a variety of formats depending on a particular ledger implementation (provided it follows the protocol specification) and IPC is as viable a communications layer as is RPC.
With such an architecture, the codebase isn't stored as a large monolithic amalgam of routines and classes to form a complete application. Instead, each client or service acts independently of all others, and a simple wallet update will not require a restart of a given ledger daemon. That said, an update of a ledger daemon will not require stopping and restarting a wallet. Scribes can keep working even with the local ledger (if you choose to run a ledger) offline. Pools can happen entirely on the p2p network, and at no point are you required to run ALL of the services yourself just to use the currency.
This is about as detailed as I intend to get regarding the 2.0 architecture that I have devised in a public setting until after I have spoken with the development team regarding what they want to do with it (if anything) . Suffice it to say, it is
not a simple task. It
cannot be implemented in a short time frame to any degree of quality, and will almost
definitely require that the majority of the codebase be rewritten from scratch.
I hope this has been enlightening for some of the less patient among you. I am not currently involved with the development team for LTCD, and if they choose to implement my architecture, that decision lies squarely with them (and I assume still the community at large). But rest assured, impatience and harsh criticisms of the developers will not likely get you there any faster.
The LTCD team has my full support and trust to ensure a bright future for LTCD as a whole.
