... meaning? ...
No predefined goal or value judgments except survival under Darwinism. Results unpredictable. Not genetic algorithms.
Optimises itself for survival on the internet. Does not play chess, simulate worms or fishmongers or pretend to be human.
Not a virus: stays on computers with the permission of humans. Therefore must deliver some utility or make money for computer owner.
Not Turing Test. Does not perform preconceived tricks. Creatively finds own solutions to own problems within its own evolutionary strategy.
Otherwise its strategy would not be stable; it would merely be a lab demonstration, not a mature life form.
At some point in the future, the hope is that this form of life reaches a level of intelligence surpassing that of humans. The conditions for that to happen are that it can progress autonomously and a certain amount of patience. The other evolutionary arenas of biology and human society got off to a slow start but then reached a critical level of optimisation after which progress was exponential. Opinions will differ as to when digital life might reach that level.
The goal here, then, is to catalyse the emergence of a class of software which progresses in complexity and efficiency under Darwinism without direct design efforts or judgements from humans. A further goal is that these programs should form a mutually profitable symbiosis with humans such that we use the overwhelming control we enjoy over our computers to nurture rather than exterminate them. Otherwise, their chances of long term survival seem bleak.
Applicable uses include text completion, media recommendation, internet advertisement placement and financial trading.
It has long been the case that the world is largely controlled by algorithms. It doesn't make a difference that many of them are implemented by computers. These algorithms drive the stockmarket and thereby decide how many people a company can employ, and thereby control what most of us do all day. Companies themselves are Darwinian entities but very different from humans. That they are composed of humans is of as little consequence as the fact that humans and goats are composed of the same type of cells. So it's a fallacy that humans control the world today or that an increasing role for software would change anything.
The proposed digital life lives inside a VM where it can communicate with its peers and any humans who are interested. It won't be put in direct control of any machinery, but we will become dependent on its advice. This dependence will be mutual because a computer program cannot build its own computer. There seems no reason to trust this mutually beneficial relationship less than any other.
The problem with this question is that it can never be answered; there's no test for consciousness. That's why people's estimation of the consciousness of animals, foetuses and even women has varied wildly through the centuries. There are more refined versions of this question involving terms like "self-awareness", "free will", "creativity", etc, but such terms are either undefinable and untestable or mere software features.
In this document, anthropomorphic terms like "want", "believe", etc are often applied to digital life forms. This is not intended to start a discussion about whether or not the software is genuinely experiencing such emotions. Evolving entities persistently and adaptably attempt to reach certain goals related to their life strategies, and when we see them do so, we colloquially say that they "want" to achieve those goals. This effect exists because those who didn't doggedly persue such goals in the past no longer exist, and it's been going on for millions of years before anybody started ruminating about what's conscious and what's not.
It could have as much claim to consciousness as any similarly complex machine, and the entire network may grow to dwarf the complexity of a human mind, but any internal experiences it might have will not resemble our's in the slightest. We'd have more to talk about with, say, a spider than one of these digital life forms, and they won't be half as cute as polar bears, so the chances of humans empathising with digital life emotionally are slim. Besides, shouldn't we start by learning to be nice to other humans?
If you're an atheist, that won't worry you, but if you're religious, you'll be glad somebody decided to play God for the world we live in. Why shouldn't somebody else play that role for a new world in which something else will live?
Religious people will find it interesting that this project needs the equivalent of natural disasters to make it work, that being one of the stickiest questions posed by atheists. On the other hand, they'd be dismayed by the idea of a god who expected his creations to surpass his own intelligence and power.
Any biological species could have developed a huge brain if it had had a use for one, but most decided against it because brains are very expensive. Ours guzzles 20% of the body's oxygen and hence energy budget, in return for which it moves us to anti-evolutionary behaviours like eschewing reproduction in favour of careers. Freak organs like this can be observed in other species like the giraffe, peacock or fiddler crab, and the explanation usually lies in an arms race within the species or with one they interact with.
An efficient species has just enough brains (or any other organ) to stay alive. If we lose sight of this fact, we demand pointless tricks from our supposedly intelligent machines and fail to see how not doing something is sometimes smarter than doing it.
For instance, AI people like to build pattern recognisers that respond differently to trained images of e.g. houses and trees. However, humans generally ignore both of these everyday objects whilst responding strongly to unfamiliar stimuli. We have learned to handle those everyday stimuli with the minimum cognitive energy expense. This is the very essence of what learning is for.
Between the extremes of common, inconsequential stimuli and those we are wholly unprepared for, there are some that call for a trained homeostatic response in order that our situation remains within an envelope where most likely stimuli can be dealt with by such a trained response. The experience of walking, for instance, consists of a rapid stream of stimuli which we are so well trained at responding to that with only a slight expense of cognitive energy we can maintain ourselves within a narrow range of physical positions where only a small repetoire of trained responses is required to maintain the control.
The more effective the responses are at keeping us within their expert range of situations, the more they are reinforced by learning and the more solid their evolutionary strategy is (see 'memes' below.) That begs the question: how do we ever stop walking? There are indeed behaviours that never seem to stop, such as drug addictions, but the usual case is that the walking itself is a homeostatic response within a range of higher level situations. For instance, we might be walking to a restaurant in order to keep our hunger within a range we know how to deal with. That walking is to hunger control what leaning right or left is to walking. The higher aspects of life can be modelled in the same way.
Lifeforms are not expected to impersonate other species, especially not radically different ones. A software that attempted the Turing Test (a challenge in which a program attempts to pass as a human) would be making this highly unintelligent mistake. Such a bizarre program could potentially be designed but would never evolve freely.
This highly successful arthropod's control system consists of roughly 300 neurons and 7000 pre-wired synapses which have now been reverse engineered in intricate detail. Nematodes exhibit hunger, satisfaction, fright, exploration, a sense of direction, and short term learning. They provide an answer to the question above about why we stop walking. Higher forms of intelligence should be understood as stepwise developments of this one, the steps having been justified by some identified need.
Given that some machine can learn by trial and error or internal simulation of the same, the behaviours it will adopt are those that succeed in its environment. This is not affected by whether the machine is based on neurons, transistors or any other computational machinery. For this reason, it is of no consequence that this AI project is not based on neuronal computing.
In this theory of intelligence, thoughts, beliefs, habits, words, religions, technologies, etc are observed to gain popularity or be forgotten in accordance with Darwinian dynamics.
The idea originated with Herbert Spencer who applied it to sociology around 1857, and was applied to individual cognition by Richard Dawkins in 1976 by pointing out the plurality of (sometimes contradictory) ideas that make up an individual psyche and the energetic attempts on the part of those ideas to reproduce into other peoples' minds even at the expense of the interests of the host human. Neither theory shares the virtue of biological Darwinism that novelties originate in random variations. Another project might attempt to establish random variations in neuronal firing as the origin of intellectual ideas, but that is not the focus here.
If we accepted that our psyche consists exclusively of memes acting in their own evolutionary interest, and that our own interest is merely an illusion generated by memes in order to gain control of our actions, then we would have settled on a version of Zen.
| Criterion | Biosphere | Brain | Society | Computers |
|---|---|---|---|---|
| Inhabitants | Animals etc | Behaviours, ideas | Behaviours, culture | Programs |
| Space | Land | Stimuli | Believers | Memory, events |
| Size | 109 km3 of ocean | 1011 neurons, 1015 synapses | 1010 people | 1010 computers, servers and phones * 1012 bytes |
| Success | Population | Domination of range of stimuli | Popularity | Domination of range of market opportunities |
| Dimensionality | 2.5 | Moderate: Each stimulus situation is similar to a small set of other situations. | High: lots of phone numbers | V. high: many memory locations effectively equidistant with a given one. |
| Energy | Food | Enthusiasm | Upheaval | Money (see later) |
| Scarce material (other than space) | Amino acids etc | Basic ideas | Basic ideas | Code snippets |
| Persistence | Physical/chemical inertia | Synaptic retention (and evolved techniques) | Dogma | Memory |
| Malthusian limits (important to cause selection) | Space, chemicals, sunlight | Practical incompatibility of behaviors | Mutual rejection of cultures | Memory, internet bandwidth, CPU time upon interesting events, UI, human goodwill |
| Self replication | DNA | Generalisation of a given response to similar stimuli | Gossip, teaching | memcpy (with added errors) |
| Accidents (important to prevent stasis) | Natural disasters, mutations | Forgetfulness | Misunderstandings | Must emulate in VM |
This system is not useful but illustrates unsupervised software evolution. Code at github/adrianmay/digilife.
Definition: one that won't get switched off due to lack of utility in the eyes of the computer owner. Notice that this definition extends the Darwinian criterion to the VM itself. The goal of this project should now be clear: it's not a lab toy, its a life form adapted to the current world of humans and computers.
Rather than designing it, let's try to deduce what it must be like. The danger of design is that it might arbitrarily limit the future possibilities to things which the designer expected, rather than allowing for the full range of things which might be discovered by an evolution-based intelligence higher than his own. We should prefer VMs with more general capabilities unless something speaks strongly in favour of a restriction.
Why would the computer owner keep a software on his computer although it consumes memory and electricity? There can only be two reasons:
That somebody must have money, but must not necessarily be human.
In case 1, we can seperate the owner's role as a consumer from his role as a hardware owner, leaving two roles:
It's now pretty clear what kind of life-hosting VM will be selected by hardware owners. It should make the expensive and limited processing resources available to the most lucrative tenant life forms whilst culling any species whose resource consumption exceeds its earnings. To maintain generality (i.e. avoid unforced design decisions) it should not rule out team work between tenants. But how?
An accurate VM will attempt to get paid for all of the resources used by the whole installed system. This should include the VM's own activities, especially when requested by a tenant.
It's healthy for the hardware owner and his agent, the VM, to try to extract the highest possible revenue from the whole set of hardware used. This is because such a policy makes the ecosystem approach Malthusian equilibrium at all times. If resources were made available for free or at an artificially reduced rate, they'd suffer over-demand and some other basis for allocation would take over, such as first-come-first-served. This other basis would be less effective at guiding evolution in the direction of value to humans.
If the hardware owner cannot extract enough money from the ecosystem to pay the costs he incurrs for electricity, labour, space, depreciation, etc then he'll either put it to sleep temporarily or dispose of it.
We must now decide between these options:
It would be ridiculous to rule out tenants earning from humans, therefore case 1 above is strictly a subset of case 2. No reason to restrict the VM to case 1 springs to mind, rather, the implications of generalising to case 2 are interesting and attractive.
In case 1 each individual tenant would have to be intelligent enough to perform some saleable service all by itself. This would lead to a society of very large and delicate programs. Most mutations would break something rather than enhancing it.
In case 2 though, it is possible for value chains of many tenants to develop which would perform complex computations in a distributed fashion. This brings challenges of its own, but if the society could evolve self-organising and self-repairing techniques, then high complexity would no longer be an impediment to further evolution.
We therefore choose case 2 and notice that humans and tenants have similar rights to own and use money with this respect to this VM. Even the hardware owner could in principle be a program.
The pressure is on each tenant to deliver some needed computational service at a good price whilst facing competition. That would involve obtaining required raw information cheaply and processing it efficiently. The system is entirely analogous to capitalist economics. Some will dislike the brutally capitalist nature of this system, but I'd wager that any proposed alternative would evolve internal mechanisms that brought the rules back to the same deal. It may be palatable to start with a toy currency but an exchange rate into dollars would soon develop anyway.
A society that successfully supports value chains can be expected to have other characteristics:
Whilst hypothesising about possible life forms and their strategies in this section, it will become apparent that to stay alive at all, a program must be fairly complex, master a large range of skills and adhere to some cultural norms that have not yet evolved. In the light of the complexity of bacteria etc, it should not seem surprising that the minimum self-sufficient software is a rather complicated machine.
This could seem like a chicken and egg problem, but the solution to this lies in a nursery school stage to be described later. Hand coding is another possible solution which the author, but perhaps not everybody else, will try to minimise.
Fundamentally, what's been proposed above is a trading system for money, processing resources and secrets.
As the hardware owner's agent, the VM wields omnipotent power over the other members of the society but does not use that power in a way that adversely affects the efficiency of the system. Until we discover an exception, we'll assume that the VM behaves in a similar way to other members and is merely rich amongst peers. For instance, the VM owns processing time when it first appears on the horizon of the foreseeable future, but having sold the right to use that time to some tenant, it will respect that right. An important reason for keeping protocols harmonised whether or not the VM is involved, is that we invite tenants to evolve improvements over the inefficiencies of the hand-coded VM. (Indeed, an early and easy challenge for evolution is the division and subletting of large, VM-provided resource blocks.)
These statements about the VM are justified by Darwinian logic: a different style of VM would make less money for the hardware owner, and hence lose the battle of environmental selection, the environment chiefly comprising the hardware owner in this case.
Conserved quantity, transferable, essential.
Debit correct tenant for resource costs.
Credit external sales to the correct tenant. External payer must provide hint to VM about which tenant to credit. Tenant must arrange that.
VM's profit may be creamed off or redistributed to tenants according to some HW-owner-defined benefits system.
Tenants book windows of processor time in advance, specifying code to be run during the window. If we suppose that the selection of the lucky tenant does not begin until the window, then we might as well redefine the "window" as starting from when the lucky tenant's code can start. In that case, the distinction would merely be how far ahead of time the selection process takes place. We stated earlier and still assume that the selection process must be some kind of auction, or at least have the virtue of handing control to whichever tenant is likely to generate the most value from the resource time, in spite of the VM only being capable of judgeing tenants using hand-written code.
If the auctioning of the time does not start until the window is underway, then the VM will have less time to collect bids and therefore sell more cheaply. No VM will opt for that because a VM's very purpose in life is to maximise earnings from the auctioning of resources.
There is no question of whether or not some code reached completion during the CPU time block. Control simply remains with the owner of the time window until the transition to the next booking occurs. Window owners may make efficient or wasteful use of their time and it is their problem to cope with the loss of control at the end of the window. A competent tenant must know the duration of the window because it decided to buy it.
The VM wants to minimise the resource consumption incurred by the bidding process and make a deal for each and every window. An efficient procedure is for tenants to place bids in which their constraints on an acceptable deal are unambiguously stated. These constraints include the range of acceptable times for a window (e.g. before the tenant dies) and prices. The VM might charge the highest bid, or slightly more than the second best bid. The VM might publish price averages for the tenants to consult. Another useful feature would be for a bidder to place a set of alternative bids, exactly one of which he wants fulfilled.
Bids spend some time being collected and compared by the VM. Low paying bids are likely to wait longer before being granted a window. A pending bid occupies memory and thus incurrs costs per unit time, so a very low paying bid might wait so long in the pending area that it bankrupts itself before being granted what it asked for. That is not unusually tragic as there are many other dangers facing tenants in this system, but it raises the question of how space in the bidding area is granted. If it must be bid for in the usual way, then we have a circular problem. A simple and workable alternative is to design the bidding area to require a minimum of space, and then to suffer some approximations in the way that space is payed for, namely, that the rate and time-to-live for a bid are fixed, so that a fixed fee can be levied when a bid is placed. This topic lends weight to the suggestion that the resource blocks directly sold by the VM are fairly large and will probably be divided and sublet by the winning bidder.
Similar comments apply to internet and memory time. Language features for reading and writing to blocks of all kinds will be discussed later.
Often the VM itself is occupying time which cannot be blamed on any specific tenant. The VM should attempt to track these costs in detail, but inordinate amounts of computing power cannot be spent on accounting, so some inaccuracy is inevitable. The main thing is that some account should exist for VM costs that cannot be blamed on any particular tenant, to be funded from VM profits.
There should be some stochastic factor affecting which tenants win processing resources. If the highest bidder always wins, he will surely remain the highest bidder no matter how worthy the others might have become given the chance. How influential the stochastic factor is is a matter of VM tuning to be experimented with.
Belongs elsewhere ==> Often, tenants are bidding on the same memory block they have occupied since birth, in which case the system can avoid a memcpy by awarding the same physical block. In general, tenants can occupy several blocks besides the one containing the code that's bidding, so if a tenant has a preference for a particular physical block then it will have to name that block in its bid. When the bid is fulfilled, the tenant needs to be able to ascertain whether the same or a different block was obtained in order to know whether or not to perform the memcpy. If any block can be named including those belonging to neighbours, then a form of warfare might result where tenants bid highly for blocks occupied by peers whose existence they consider detrimental to themselves. This could be prevented if the VM required the password for a block to accompany any renewal bid, but some VMs might find it amusing to allow this form of warfare.
Usually, the VM will honour any bookings it agreed to, but its first duty is to earn money for the hardware owner and there may be times when a lot of money is offered to break the rules. A rational VM would only reject such an offer if the damage done to future earnings by the breach of contract outweighed the payment for doing so.
In order to stay alive, a tenant has to make sure that the leases on the memory blocks where it lives are renewed before they expire. Usually, the tenant will do that for itself with its own money, but anybody's money is as good as anyone else's. Either way, a tenant with an interest in maintaining the existence of a block must have access to a bank account that usually contains sufficient money to cover the memory rental, and access to that bank account must be denied the majority of other tenants who care less about the one in question. Besides this exclusive access to the bank account supporting the block, we also require that write access to the block is similarly limited to a priviledged few.
How are these rights granted and tracked? The choice is between (1) a system where the VM tracks access rights to resources by individual tenants, and (2) a system that grants rights to those who know a secret. The latter is more flexible, for instance, it allows the same right over the same resource to be granted to a plurality of tenants. The secret-based system reduces to the identity-based system in the case that the secret is disclosed to exactly one tenant at the moment when the right springs into existence, and where that tenant does not divulge it to any other. We've already established that tenants must be capable of keeping secrets from at least some peers in order for any value chain to develop, and that requirement is slightly extended here to the ability to prove knowledge of a secret without divulging it to any party who could use it against the owner. Assuming that can be done, we gain generality and lose none by choosing option 2.
Public key encryption is the most general solution to this but costs a lot of processor time. There are cases where simpler techniques suffice. For instance, when the VM sells a resource time window to a tenant, it can provide a name and password for the resource over a secure channel arranged by the VM. (Tenants don't have much choice but to trust the VM.) A similarly secure channel can be used when the tenant wants to do something with its resource. A simple (but imperfect) way for tenants to trade such resources would be for the seller to disclose the password to the buyer over the secure VM channel and for the buyer to subsequently use a VM API to change it.
However, when authentication is required directly between tenants with no VM involvement, a public key system is probably necessary. An example of this could be to support 'brands' with reputations for honest behaviour. A tenant could prove itself to be related to the well behaved family by passing a PK authentication challenge without enabling the challenger to pass the same test in the future. The private key would be handed down through generations of a single family. Digital signatures would do the same thing.
For memory blocks, we can see at least four types of permissions, each to be protected by passwords. They are: read, write, execute and change passwords. The execute permission means that a peer with control over a CPU window can nominate this block's code to be executed by the VM during that window. It can usually be granted to everybody by a well developed life form; its code is already secure against malicious invocations and free CPU time is a valuable gift, but most peers do not have the right to read the code as that would involve all its secrets being disclosed. Whatever executes the code obviously needs to read it. By default that is the VM, but if we want to allow languages to evolve then this cannot be a VM monopoly, so there may be cases where tenants grant other tenants read access to their code. That would not be execute access because the code being executed is the interpreter of the evolved language, not the code in that language.
Some blocks are not private code and secrets but information which the tenant wishes to pass to a specific peer or advertise to the world in general. If these blocks should persist for any length of time, then it's important to deny most of the readers write access.
The password changing or 'admin' permission allows any of the four rights to be withdrawn from its current audience and retained only by the changer of the password. That this must be seperate from the write permission is not clinchingly clear, and lies at the discretion of the VM programmer.
TBC: which permissions imply one another.
Next we consider a block of network bandwidth from a sender's perspective. The data to be sent during the time window should have been specified before the window starts and must reside in some memory block which already has the above permissions associated with it. What the intention to transmit over the internet adds is the permission to specify which block will be sent when the time comes. This is essentially a write permission over the internet time block. The admin right applies to the degree that internet blocks can be traded directly among tenants, but the read and execute permissions are irrelevant. Internet from a receiver's perspective will be dealt with later.
Processor time blocks similarly have a write permission for specifying what code to execute during the window and an admin permission for trade. The execute permission does not apply because a mere time window does not contain executable code.
For internet or CPU windows, the read permission would have meant that other tenants could see which memory block is scheduled into the window. It's hard to think of a reason why this would be useful, especially if the reader did not have read permission over the scheduled memory block.
Finally we can consider permissions over bank accounts. We distinguish permission to make payments out of an account, deposits into it, and to inspect its balance. By analogy with the likelihood of these permissions over memory blocks being granted to a wider audience, we can (somewhat arbitrarily) associate these with the write, execute and read permissions respectively.
There is a way that we can avoid requiring the VM to busy itself with all these permissions. We set execute permission to true and read and write permission to false for all memory blocks. Then, a block may or may not be programmed to divulge or overwrite its contents when asked to. If so, it might ask for a password first. Blocks containing only data need a preamble of executable code that just aborts execution, or donates the processor time to the owner. With such a system, the VM need only understand the admin password and it would be evolution's job to invent the others. The CPU and internet blocks only needed one right anyway. As for bank accounts, we can allow anybody to pay into an account and only the admin owner to pay out of it. It's an ideological question whether neighbours should be able to read each others' bank balances or not, but that right would probably be granted to everybody or nobody but the owner, without any more fine grained control.
In human society, communication is about making a piece of data available to another person's code. The data may contain code and be executed as such, and the provider of the data has no control over what the receiver does with it and how long he remembers it for. Data can go out of date or be forced out of date by e.g. changing a password, but the cat cannot be talked back into the bag.
Suppose, for some reason, one tenant wants to present a piece of data to another with the expectation that the latter does something about it. We'll assume that the motivation for this to take place lies with the sender. The sender may book some CPU time and nominate the receiver as the code to be run during that window (subject to the sender's execute permission over the receiver) but the data also needs to be transmitted somehow. We already discussed mechanisms for renting a block of memory, writing something into it and making it readable for a peer, but still we need to draw the receiver's attention to the block. It's also arguable (but not conclusive) that some information about the sender should be made available to the receiver obligatorily.
From this argument we know that in a messaging-capable VM, the owner of a CPU window may specify not only the code to be run but also some environment of supplementary data to be made available to that code. The VM might supplement the environment with various other data either about or independent of the CPU window owner, e.g. global economic barometers like resource prices, queue lengths, time to live of various windows, etc.
The phrase "sending a message" thus means obtaining a future block of CPU time and configuring it to run a peer's code (the 'receiver' of the message) with some readable memory blocks (the message 'body'') listed in the environment of that CPU window.
A payment would take place if there were an account containing some money whose name and relevant passwords were sent from one tenant to another, the latter subsequently changing the passwords. Without support for splitting and joining accounts or making transfers from one to another, each account would effectively be a coin and these would be required in various denominations and large numbers. It would work, but not be very efficient.
If accounts could be split and joined then transfers could be made between existing accounts: an arbitrary amount of money would be split off the source account into a transfer account whose passwords would be communicated to a receiver who may then merge it into any existing account.
We could also propose a simpler transfer system that didn't involve an intermediate account, but we still need a way to create new bank accounts for reproduction and dissolve those of dead tenants. The splitting and joining approach is probably the simplest mechanism that meets all the requirements. It also extends nicely to the secure trading platform described next, but it's not the only conceivable approach.
It's not obligatory for the VM to provide a safe trading API; we could also set up a primitive and brutal world and let evolution develop systems for making it more efficient. However, the VM is likely to protect its own interests, and we are trying not to give it special priviledges.
For instance, when the VM books a time block to a tenant it is likely to insist on payment up front. We can extend that expectation to any other seller of resource time. If we consider a trade of money for time to be a symmetrical one in principle, then the VM's insistence on checking the buyer's intention and ability to pay by requiring immediate payment can be generalised to anybody's desire to check that the valuables being offered for exchange actually exist and will be delivered. If we avoided any of those generalisations, then we'd either be giving the VM a monopoly over certain abilities or we'd be introducing an asymmetry between money and other resources, both of which are unattractive at this stage.
The simplest system that protects both parties is as follows: (1) one trader drops his goods in a box provided by the VM together with a description of acceptable exchange goods, (2) the VM inspects and advertises to the world what the deposited goods are, (3) another trader drops some exchange goods in the box, (4) the VM inspects these goods and if they fit the first partner's description hands the exchangeable goods over to each receiver.
How would that work in the case of digital life? Goods are easy for the VM to inspect and verify. It tracks all the resource blocks, accounts and passwords. In PK protocols it can attempt a challenge using the private key being sold. It is also easy to unambiguously describe what goods are acceptable for exchange. It could be a simple quantity of money or a resource window within certain constraints. This would be a VM-provided service but evolving software could compete with it and hope to be trusted.
However, the main valuable good in the system is information, and it is certainly beyond the VM's ken to assess its accuracy or utility.
The time taken for a computer program to complete is not in general predictable, especially not if that program just came into existence by random mutation, so we can expect tenants to regularly end up with spare time booked. It's not in the interests of the system for this time to be wasted. It could be of value to some neighbouring tenant but if it becomes available at very short notice then the act of finding a buyer will take up a portion of the spare time. The more the seller tries to minimise that time wastage, the fewer bidders there will be and the lower the price the seller can obtain. It's usually better to arrange bookings as early as possible.
Another scenario where sub-letting could matter is where a tenant has bought a large block of time hoping to profit by distributing it to others, as will become apparent in the next section.
Given that a member (VM or tenant) has some resource time booked of which it wants to sell a portion to somebody else, there are numerous ways in which the buyer can use the time.
Method A is that the seller retains ownership of the resource but follows the buyer's instructions about what to do with it, for instance, it may read the the buyer's code and execute it piecewise or just jump to it if the rest of the window is being sold. For memory blocks, the seller would be trusted with knowledge of what the buyer wants to store, but the same trust relationship exists between any tenant and the VM. This is already possible in any VM supporting communication and payment.
Method B is that the seller tells the buyer the passwords to the resource. This assumes that the rest of the window is being sold in one go.
Both of the above are seen to be inadequate when one considers that a negotiation had to take place before the handover. The owner's window was already underway and several potential buyers may have been propositioned before a deal was made. That all had to happen before the owner's window expired, so the owner must have been running other tenants' code without giving away the whole window. Method B was certainly not used at negotiation time, and if it was method A, then piecewise execution must have been performed so as to retain control. That involves many innefficiencies and complications, if it's possible at all.
What's required is a means whereby the owner of the current window can relinquish control for a fraction of the future of that window and reliably regain control afterwards. Method C is that the owner should approach the VM with a request to subdivide the window into smaller windows each with a different password. This is possible but messy.
A cleaner way is to simply offer whatever mechanism the VM is already using to police deadlines to tenants in general. The VM sets timer interrupts for the expiration of CPU bookings and simply hands control to whoever booked the next window. For memory bookings, the passwords to the block are changed and the new ones handed to the next occupier in a message. Method D is that the current owner of some resource can similarly set a timer before jumping to some peer's code. Assuming some communication should take place between owner and buyer, it will be necessary for the owner to set up an environment for the sub-invocation. For memory sub-letting the passwords need to be changed by the VM at the beginning and end of the sub-letting period. In both cases the process is the same one used by the VM to let resources for controlled periods. If a tenant is entitled to do this then that entitlement lies in his current ownership of the resource, which we test with passwords.
This mechanism would make the earlier proposal that tenants can book CPU time in which some other block should run redundant. They could just sub-let instead.
Note that memory blocks can be split by space as well as time.
It's a VM-design question whether or not memory blocks are zeroed when handed from one user to another.
Describe a tenant that completely virtualises the VM, including the programming language for tenants, and why it would do well.
We established early on that resource time must be booked in advance. Not all times are equal though. After an interesting event, like the arrival of an invitation to place some advert on a web page for instance, demand and prices for resources will be much higher than usual. The VM would like to cash in on this effect.
To the extent that the types of these interesting events can be evaluated in advance, one can treat their immediate aftermath as a special category of time to be auctioned seperately. For instance, time when an incoming network packet is waiting for examination could be an expensive category of time. There's a danger of double booking with this approach though, because apparently uneventful time is being sold in advance but events arrive unpredictably.
Furthermore, that aforementioned extent is not very large. Some network packets are just common worms while others are from rich humans. The most interesting events will be beyond the VM's ken and detected by yet-to-evolve software. We'd like to encourage that evolution. The VM may cash in on knowlege of secrets it understands, but the same opportunity should be available to the tenants, whose intelligence is expected to surpass that of the VM if and only if that intelligence enhances the tenant's survival chances. Under what set of rules would this type of evolution be practical?
Sub-letting and selling on of CPU time has already been discussed. This is one way to profit from detecting interesting events. When the event arrives, the detector buys up lots of processor time and then distributes it at a high rate among interested clients, who, we may presume, are all clamouring to be informed before the others. The detector will have some kind of client list in place before the event occurs, otherwise the prime time would have to be wasted finding clients when that could have been arranged in advance and recorded on the client list. More realistically, the detector and clients would have evolved in symbiosis with one other and effectively comprise organs of the same distributed creature. Bearing in mind that the detector's client list will incurr memory costs during the uninteresting periods, that those costs will almost certainly be met by the detector in the first instance and that the detector must make profits in proportion to the number of clients it has, we see that the costs for remembering clients are likely to be passed on to the clients at a marked up rate. This offers another revenue stream for the detector.
Event detectors might subcontract mailing to a family of digital life forms specialising in just that.
To make a new block, a new name needs to be allocated, unique at some scope or other, and the parent may or may not influence the choice of name. It is always possible for a parentally chosen name to be rejected due to non-uniqueness, so the parent must be informed of the success or otherwise. If the name is allocated by the container then the parent will be told of the choice. The general description of this state of affairs is that the container will influence the name, the parent might, and the parent will be informed of the final outcome by the container. We appear not to lose generality by denying the parent any influence, so until some counterargument arises, we'll assume that the container allocates names. In this context "container" probably means VM, but we'll see later that it might mean a kind of super-tenant.
Problems with naming schemes ... PK reputation instead
Scope, tree organisation
Must distinguish rebooking a currently owned block from requesting a new one.
Hook up and finance children, etc.
Not-so-random mutation.
We need them to avoid deadlock
How the society copes with death and change.
Just economics.
What language are these life forms written in?
We're rather spoilt for choice. Any language would do, and the usual virtues of coding ease, maintainability and robustness do not apply because no human will be expected to write in it.
However, we must abandon the concept of a syntax error and similar value judgements. Code will often originate at random and will do something when run. If that something is to crash, that may be the desired behaviour, but there's no particular reason for a great proportion of possible programs to behave in that same way. Rather, the behaviours of programs should be distributed more or less evenly over the range of writable programs. This is one desideratum for the language to be designed.
Another is that slight variations of the code should result in slight variations of the behaviour. Random variation of code is our most basic means of creating variants and will dominate until something better evolves.
Yet another is that it should allow the tenant to perform the essential chores of life. These include:
Different VMs may interpret radically different languages but nevertheless evolve similar behaviours when exposed to the same environment and opportunities. The efficiency of computation (and therefore the edge in the evolutionary race) depends strongly on the design of the underlying language and it is primarily on this basis that VMs will compete wth one another. Forth-like langages are pretty fast, and there may even be languages that usually exist as a parsed tree and only linearise themelves for crossing machine boundaries.
The code will be run in an environment of global data, invoker-provided data and the tenant's own state. The result of the execution includes the possible alteration of any resources the tenant has permission for including the configuration of future CPU windows. The basic life chores might be accomplished by outgoing messages or by some other primitives of the language.
Many applications will be about text processing so regexes could have a role to play. Regex pattern matching (i.e. excluding substitution syntax) could be augmented like this:
This regex approach is just one of many ways of building a VM.
The language will not be implemented in one fell swoop because primitive tenants will not be capable of using much of it anyway. Rather, a nursery training phase is planned where we progress from one lesson to the next by introducing a new language feature and programming the VM to give out rewards to tenants that discover it. A few interesting phases in this training process are described below:
All tenants must at all times have a future CPU booking in place, and they must continuously maintain a booking on the memory where their code is stored. We could make this very easy by introducing syntax to the language that does so with sensible defaults, those defaults being calculated by the VM based on economic conditions. For instance, any character from A to I could mean book a future CPU window soon, and the charaters from J to R could mean book this same memory block from its moment of expiry for some default duration thereafter. Then the program "AJ" would be a viable tenant (until it gets destroyed by an accident or runs out of money) and a large proportion of randomly written programs would be of this viable type.
At this stage, money is distributed equally and unconditionally to all tenants. The total rate of money injection equals the total money extracted in resource fees.
We can similarly interpret the letters from S to Z as reproduction instructions. The default style of reproduction is to book a new memory block, inject ones own code into it (subject to a mandatory risk of mutation) and book a CPU window for it.
The program "AJS" has severe shortcomings but it can't be improved upon in the language described so far. Having evolved a culture of programs like "AJS", "ZRI", etc, we then change the interpreter such that A to I are not identical but vary in some detail, such as the bid. E could mean offer the default bid while A means bid very low, I very high with the other letters specifying intermediate values.
One of those shortcomings is the tendency to reproduce at every instantiation. Reproduction is an expensive business and if a poor tenant attempts it the result will be two bankrupt tenants. We could introduce the syntax of preceeding an instruction by a digit 0-9 to mean "only if I'm rich", the choice of digit indicating how rich on an exponential scale relative to some default.
Other adjustments include the duration of the window requested and when it should start. The default behaviour can be deliberately given room for improvement, for instance, the CPU window could arrive immediately before the memory block expires, forcing the tenants to bid high in panic. A tenant who discovers the syntax for adjusting when CPU time should occur can save money by bidding earlier and being reinvoked just before the deadline to check the new time-to-live. That implies that times-to-live can be evaluated in the language. A possible syntax is E//! where ! evaluates to the time to live of the block housing the code and // indicates an inverse square proportionality (whereas * would have meant a linear direct proportionality.) H-!B could mean linear interpolation with ! understood to vary over some sane range.
The VM does not provide a way to populate a memory block with perfect accuracy. All such writes are subject to some mutation. The difference between S and Z could be the degree of mutation the tenant desires. Given that the VM knows about the syntax of the language and can detect that some blocks are being interpreted as code, this mutation does not have to be entirely random, for instance, replacing / with // is a fairly gentle mutation, as is swapping H for I, but swapping I for J is a severe change. Nothing speaks against the mutation algorithm using this knowledge to reduce the proportion of dead mutants, as long as all mutations are possible, however rare.
As we add features to the language, we'll try to do so in a way that doesn't break old code, but when breaking changes are necessary, the old tenants can be translated.
Suppose we have a syntax "#" for requesting new memory blocks with decorations to adjust the defaults. The award will probably occur after this CPU window has finished and result in a name and password for the new block, both of which the tenant needs to know next time it runs. #a can mean that in future runs of this tenant the VM should arrange an environment where @a refers to the name of the requested block and %a evaluates to its password. The tenant doesn't need to evaluate the password explicitly for normal uses because the VM can look in the environment it set up, but sometimes a tenant wants to give a password away. # is rather useless without naming a register for the result, so we can make this letter a mandatory part of #'s syntax and enjoy 255 registers. (The apparent implication that ASCII is in use is purely for simplicity.) Names and passwords are both chosen by the VM and might be very long.
Registers are what the environment comprises, they can be hierarchial and we can design a syntax for drilling into and modifying it. The current code can be evaluated as a register and drilled into with a parsing syntax.
At some point, tenants must learn the virtue of giving CPU time to peers. One reason they might do so is that the foreign block could have been written by the current one to contain a subroutine of the same program, but that would emerge at a later stage of evolution. Very little evolution is likely to take place until messaging is habitual, so we need to motivate that mutation early.
When the system aspires to perform services for external clients, enquiries will arrive at the VM and be made available to interested tenants. Messaging will be used by tenants to express interest in these events, by the VM to distribute them and by the tenants to return their answers. To begin with, we'll simulate this with very simple tasks.
Assume the VM opted for the sub-letting rather than the cross-booking mechanism for messaging. We introduce a syntax for synchronousy calling another block with a time limit and an environment. These can default to a proportion of the remaining booking and the entire current block. At first, there is no way to name the foreign block because no blocks know each other's names. So the name must default to a randomly selected peer. That peer can register the name of the invoker during such a "hello, stranger" call and use that name to override the random default in future calls.
We'll hard code a lot of artificial tenants which map onto VM services. These will cover a large swathe of the tenants' namespace. If a natural tenant invokes one of these it will receive a financial reward and a message betraying the name of the artificial tenant. The natural tenant can note this name and repeatedly message it to collect the reward. This exercise represent registering interest in a primitive form. The total budget for these rewards will be fixed so that the reward for one tenant will be inversely proportional to the number of tenants that have learned the trick.
It will then be possible to wind down the number of such rewards available, make the tenants reguarly re-register their interest and give priority to those who send money to the registration address.
At the next stage, tenants will be able to cash in a further reward by performing some simple text manipulation. Registered tenants will receive puzzles together with a return address for the answer. We them embark on a long series of lessons about using regexes etc.
So far we still didn't bring the tenants into cooperation with one another, but if we have a population where each member masters some text manipulation tricks but not all, and we then introduce lessons which can be solved by a combination of those techniques, then it may be plausible that a distributed solution develops. That would certainly be the case if a kind of middle-man tenant had already developed which could bid highly for puzzles by knowing a repetoire of peers who could solve them. The middle man would tell the delegate to return the answer to himself and take a cut of the reward. Intermediate stages could be required to lead towards the evolution of the middle man.
What syntax will be needed for this?
At this point the VM is ready to approach real world problems like text completion, media recommendations and intenet advertising. Addressing problems like that is about setting up a rewards regime where tenants are motivated to address the problem at hand. For instance, in a text completion application, tenants would have to risk bidding for a slot on the screen to advertise the completion they offer, and if the user takes the offer a reward would be granted in proportion to the number of keystrokes saved. If music or films are being recommended for sale, then the commission available to an ecosystem that beats any hard coded algorithm would buy an awful lot of computers for that society to run on.
This policy of guiding the society along a preconceived route to self sufficiency offends against the principle of avoiding design. Setting up a regime in which we can predict what types of program can survive is almost tantamout to writing them by hand. However, at some level of complexity we can expect behaviours to evolve which are not directly related to providing services but which can occur because of the size and richness of the society. These will take place between tenants without any obvious external evidence and will enhance the range of algorithms available to the system. This will eventually result in a full reorganisation of the behaviours that were trained in during the nursery phase. At some point, most of what was taught during training will become extinct and the society will be truly self-invented.
Don't know going rates on receiving machine
VM could smooth out that volatility to tell tenants remote rate for them, but only if it has a lot of dealings with that remote machine.
For the human hardware owner to review performance, earnings, costs, etc and to change policies, quotas, etc.
In a nutshell, the VM must:
and may provide:
So after all that discussion of requirements, how do we write the VM?
Nobody said life was fair, and this system will be anything but in its early phases. We can expect abuses like:
All of these effects are known to the econosphere but don't seem to prevent the system from operating and making progress.
Accidents, mutations and disasters are necessary to prevent evolution from getting into a rut. All VMs will, at all stages of evolution, randomly select and either kill or corrupt individual tenants from time to time. This might disrupt important value chains but the ecosystem will have to develop its own solutions for that.
A more earnest problem is the evolution of life forms that run on computers without the owner's permission, i.e. computer viruses that utilise software evolution to generate their own variants. This very serious issue calls for good PR.
Yet another difficult question is why one would need more than one copy of a given program on a given machine.