AURUM (by alaric)
My recent thoughts about bitcoin reminded me of earlier thoughts I'd had about digital currency.
Cryptographic digital currency is a way of transferring value without trusted third parties being involved in every transaction, but within a closed domain, it's easier to go for a trusted party and cut out all the crypto maths. Which is why we have printer credits managed in a central database when we use a shared printer. We may use a digital currency to buy a credit, but once we have credits, we're happy for the owner of the printer to just store our balance in a database and decrement it whenever we print.
And within a company, complex processes are used to transfer money in and out of the company's actual bank account, but budgets within departments are usually allocated by just asking somebody to update a spreadsheet. Money moves within the company using easier, faster, simple methods than bank transfers, writing cheques and letting them clear, or exchanging cryptographic keys.
It's the same story for "ulimit" mechanisms in computer operating systems, and language-level sandboxes, that allocate budgets of things like CPU time and memory space to software running in a computer.
So, when I set out to design AURUM, the resource limit system for ARGON, I decided to make a unified abstraction across all of the above. A process has a budget, which contains arbitrary amounts of arbitrary resources; and it can subdivided that budget into sub-budgets.
That's just an accounting system, though. It needs to integrate with actual resource managers. For something like CPU time, for efficiency, the scheduler probably wants a nice simple machine word reserved for "jiffies in the budget" attached to a process context in a hardcoded way. So the AURUM system probably needs a handler for "run out of jiffies" that takes more from the actual AURUM budget and "prepays" them into the process context - and when the process' balance is requested, knows to ask what's been prepaid and not yet used, so it can report honestly. If the process is stopped, any remaining balance needs to be put back in to be re-allocated to the parent process' budget. And so on.
Similarly, interfaces to actual electronic banking (spend money in a budget by causing an actual bank transfer, or bitcoin transaction, or whatever to happen), and interfaces for incoming budgets from external sources (a bank account interface that fires off a handler when an incoming payment is detected - with that payment as the handler's budget so it can then allocate it appropriately), and so on, can be built.
And a power-constrained mobile device might have joule budgets - and operations such as driving motors, transmitters, and lights might use them up. That would be neat for handheld computers and deep space probes, which can then run less-trusted code in a sandbox with controlled access to expensive resources.
That's all well and good as a way to manage finite resources in a system, but the next level is to take a step back, look at the system as a whole, and see how this facility can be used to do other cool stuff.
This leads naturally to the semi-forgotten discipline of Agoric computing which seeks to make marketplaces and auctions a core tool to solve resource allocation problems. This has scope within an ARGON cluster, if it's shared between multiple organisational units, which can then use budgets purely within AURUM to manage their shared use of the computer resources and to contribute towards its upkeep accordingly.
But, more excitingly, with mechanisms like Bitcoin allowing for money to be transferred across trust boundaries, it starts to become practical to think about allowing our computers to participate in economies between them. What if my desktop PC and servers rented out their space disk space, CPU time, and bandwidth to all comers? And with the money they accumulated from doing so, in turn rented offsite disk space for their backups, and when I gave them a particularly tough job to do, hired some extra CPU and bandwidth to do it, dynamically? Without me having to hand-hold it all as the middleman, pulling my debit card out to pay for resources... If I wanted to do lots of resource-intensive work I might put more money in from my own pocket to give it more to hire extra resources with; if I tend to under-use my system and it makes profits from renting out spare capacity, then I could take cash from it from time to time.
I guess the first step would be to create standard protocols in AURUM for things like auctions and commodity markets, to facilitate transferring between different 'currencies' such as CPU time, bitcoin, fiat currencies, printer credits, disk space, and the like. And a standard interface to bank accounts, where balances and transaction histories can be queried, and transfers requested. A bank account in the context of AURUM would be a third party that holds control of some budget on your behalf, so it should look like an ordinary budget in every way possible. That would make it practical to have software that needs a given resource to find a way, through a registry of trusted markets, to convert them into the resources it wants.
That'd be neat...
Fri 13th May 2011 10:42 am 
Subscribe