Anatomy of a future-proof local currency system
|
This is an effort to demystify local currency transaction system anatomy. I don't claim to be a specialist in these technologies, but offer this as a general, bird's-eye perspective. -- Infomaniac
Contents
CMS frameworks
Many of the more modern implementations of online transaction systems are based on Drupal.
Drupal is an excellent CMS framework. Its UI and workflow design are exemplary. It certainly would not be a waste of time becoming familiar with it. That being said, there are some caveats that preliminary investigation has revealed:
Drupal is based on PHP, thus, its security can never be air-tight. Moreover, there are legitimate concerns about its scalability; these two factors probably will be a deal-breaker for a community, intercommunity, or global scale transaction system.
Also, being server-side, it is doubtful whether it can be adapted to a peer-to-peer, distributed, serverless model, or that it can ever be separated from the MySQL database server.
Drupal may be useful as an application prototyping environment, but we have to be careful not to paint ourselves into a corner, as all the code in Drupal will have to be re-implemented to another platform.
A better platform candidate is Plone. Plone has a very advanced model and was designed to be p2p-ready, since its storage model is abstract. Since is it based on Zope and Python, there is a much steeper learning curve from a development standpoint. As far as the CMS framework, Plone is comparable to Drupal; it has all the modern acoutrements that Drupal offers, and then some.
Although Plone is p2p-ready in the sense that it supports XMPP, its distributed database model may not be viable for a massively scaled system.
The best environment appears to be Pier, a scalable p2p platform based on Seaside, a content management framework written in Squeak, a modern re-implementation of w:Smalltalk.
About Voucher-Safe
Let's use some analogies to help shed light on how the Voucher-Safe system works. It's developed by the same people who created Pecunix, a private digital gold-backed currency.
Peer-to-peer
First, to be sure we are speaking the same language, let's talk a bit about peer-to-peer (p2p). Two well-known p2p systems are:
- Bittorent (and its many variant clients originating from Napster) and
- Skype
Both perform practically all functions, from storage, messaging, and authentication from the client. These systems function by virtue of the sum total of all members of the client base.
All message or file traffic is routed in parallel through various peers that give the network stability, persistence, and better throughput.
There is no distinction between client and server aspects of the software, there is only one software defining the operation of a node in the network.
Public (asymmetric) key encryption
Skype uses strong public key encryption (transparently to the user). Now, most bittorent clients can use some form of encryption to obfuscate the data being transmitted, but not necessarily who is sharing with whom. In the world of traffic analysis, who the communicants are, is often at least as valuable as knowing the contents itself.
Distributed storage and indexing
Both Skype and bittorrent perform storage for other peers while they are offline.
Until recently, bittorrent also required one or more central servers to index (find) other peers that have parts of the stored file. This is no longer universally the case; some BT clients have a distributed index database that lives 'in the cloud' - meaning that the data is actually stored redundantly in a network structure (like bittorent) and indexed by what is generally referred to as a Distributed Hash Table (DHT).
More recently, there have come into existence services that function similarly, called Content Distribution Networks or Content Delivery Networks (CDN), such as Coral CDN. They basically store large, static media files "in the cloud" in the same manner as skype and bittorrent, taking most of the load off the webserver.
The idea is that this database, and thus the network, cannot be attacked from a central 'weak link' (the server). Likewise, an accidental outage or server overload will not bring down the system either (as recently happened to Skype's authentication indexing - this problem is of course, the analogue of the recent infamous government seizure of DNS registrations).
Another example of distributed storage and indexing - a distributed search engine, is YaCy. It only indexes data that is shared via YaCy's p2p network. Since the population of users and files in the YaCy network is sparse, it is an embryonic distributed storage and retrieval network in the sense that it has not accumulated enough critical mass to be useful and could possibly end up a failed ecosystem.
Authentication
Skype does require a central server (actually, one of a group of 'supernodes' - and now, mega-supernodes) for login authentication data storage. Skype currently has no distributed index for user authentication; as recently witnessed, this is a major weakness of Skype.
Onion routing
To thwart traffic analysis (spying and logging) on the part of the ISP, the government, or hackers another layer of obfuscation is required. A great example of this is TOR (the Onion Router). Again, all operations are performed by the peer clients. Traffic is routed over many 'hops' through many jurisdictions, via various peers, in parallel. Only in this case, each hop is encrypted with public key crypto in multiple layers (or tunnels), so that NO node of the network knows the ultimate destination or sender of a data packet or stream. Care is taken to avoid repeating a particular path, or to allow the timing of messages to be correlated. It is practically impossible to reconstruct any information about who is talking to whom.
The Voucher-Safe network uses all of these concepts in its architecture. So we have peer-to-peer, parallel routing, messaging, public key encryption, distributed data storage (DHT), distributed content delivery, and onion routing, with total anonymity. Voucher-Safe currently implements all this in a java-based client. Actually, client is probably not the appropriate term, as it evokes the notion of a browser or thin client; all the VS clients essentially create a server farm, or server cloud. So it is kind of a Frankenstein browser, webserver, messaging client, and database. All working together, it is much more than the sum of its parts, as its distributed nature is the real power of the system.
VoucherSafe, LETS, Time Banking transactions
VoucherSafe is very different in concept from LETS. LETS is functionally not much different than a bulletin board or bug tracking system, craigslist, ebay, or a dating website. It matches offers with needs, and has a central accounting system. LETS is best described as a favor-balancing ledger. The balancing is not strictly enforced, generally, so the balance sheets are more like fuzzy karma credits than currency.
LETS in its current centralized server implementation, can only offer anonymity or privacy between users using SSL, like the dating site or craigslist, but the identity of users is necessarily known in the server's database, as well as a complete transaction history and the balance of user credits. This information must be entrusted to the server operator, and could be compromised by lawful action, or action under color of law.
Time-banking, and other forms of mutual credit, go a step further than LETS, in that some measure of objective valuation is attempted, in this case in some measure of work, or energy expended. The concept is complicated when economic reality demands a different 'weight' for the time of one person, say a lawyer, than for the of a unskilled laborer. This inevitably leads to the same problem as barter, where the state may attempt to value 'in-kind' transactions in terms of the central bank fiat 'legal tender,' for tax purposes. The existence of the centrally-stored transaction history, is irresistible to agencies of the State, and will be compromised.
VoucherSafe, on the other hand, was designed to provide total anonymity. It is possible to pay someone having no idea who the payee is, and there is absolutely no possibility for a third party to discover the identity or location of the parties. There are no accounts in the system, in the manner of a bank or barter exchange. Only the user knows what he has, where it came from, and where it went. This information is stored in each user's digital wallet. So it functions analogously to cash, not like a checkbook. The simplicity from the user's perspective, though, is that a payment is nothing more than an instant message delivered securely, and irrevocably. Valuation of a voucher is backed by assets that are banked at independent storehouses subject to third-party audit and certification. These assets could be precious metals, or pork-bellies, or more complex intangibles.
Anonymity vs Transparency
Anonymity is all well and good between private parties, but there are certain situations that are easy to envision in the near future, that would demand a certain degree of transparency. What about collectives, cooperatives, joint-held businesses, even local civil bodies? These all require some accountability at one level or another. In organizations, it is necessary to be able to produce non-repudiable purchase orders, bills of sale, asset statements, etc, especially when a community needs to pool resources for the common good. In such scenarios, an anonymous cash-like digital currency like VoucherSafe and a favor-balancing system like LETS would be inadequate.
There are various conceptual models that are legitimate, depending on the use case. Thus the application model, will have to be open API, so as to accommodate different kinds of activity from public to private.
I2P
One important topic that we will need to study, is dependency on the centralised DNS system. VoucherSafe, currently does depend on DNS. The future-proof system must not depend on DNS. At a minimum, it will have to use fixed IP addresses. I think we will discover that this too, will be subject to 'traffic shaping' - prioritizing, filtering, and blocking - a lá the Great Firewall of China. That is an inherent vulnerability of IP.
Open Transactions is built on the I2P infrastructure.
I will be good to to look into the I2P network, if the transaction system is to be future-proof. It is not hard to imagine that one day, the whole internet as we know it will cease to function because of the centralised IP/DNS system.
As an analogy: we all get phonebooks thrown on our doorsteps every year. But no one uses them, except folk who don't use the internet. Everyone else uses google or another search engine to find phone numbers. We store our favorite numbers in our cell phone contacts. Few of us actually commit most phone numbers to memory, and we become dependent on google and our electronic contacts list. If we lose the cell phone, we lose all our contacts if we have not backed them up. One day, the phone books will probably cease coming as they become obsolete and recognized as wasteful. When some unforeseen event or development deprives us of the use of the search engines and our cellular phones, this spells catastrophe. Manipulation of DNS and of search engines would bring about a similar catastrophe.
I2P itself is more mysterious, but basically, what I get is that it functions in a manner similar to Onion Routing, but way more paranoid. It has its own distributed domain namespace that is not subject to any regulating body. It is essentially an internet protocol that is:
- inherently 'dark' or opaque (free from blocking)
- inherently anonymous (free from logging),
- encrypted (no spying),
- distributed indexing (no need for google - do they see this threat to their business model?),
- does not have a centralized domain name registry (no DNS vulnerability).
- authentication data is distributed in the cloud (has no centralized authentication data storage)
- is not subject to a self-appointed certification authority acting as a governmental proxy
