Tierra Working Group Report

Tom Ray

ATR Human Information Processing Research Laboratories
2-2 Hikaridai Seika-cho Soraku-gun
Kyoto 619-02 Japan

4632 N. Rockcliff Road
Tucson, Az 85715

3008 Madison Avenue
Niagara Falls, N.Y.

___________________________________________________________________
                  |         Internet: VISHART@ubvms.cc.buffalo.edu
Joseph Hart       |     /// Plink   : OSS542
Niagara Falls, NY | \\\///  Ham call: WA2SND
                  |  \XX/   FreeNet : af804@freenet.buffalo.edu
                  |     *** AMIGA - Computers for REAL MEN ***
===================================================================

Programmer Analyst II
Psychology Department
UC Santa Barbara
Santa Barbara, CA 93106

Pilot Software    (15-12-94)
1 Canal Park
Cambridge, MA 02141

Sun Microsystems Inc.
2550 Garcia Ave
MS UMIL06-07
Mountain View, CA 94043-1100

San Diego Supercomputer Center
P.O. Box 85608
San Diego, CA 92186-9784

210 Clayton St.
San Francisco, CA 94117

Funding

Charles Ofria, whom was visiting SFI to confer with Stuart Kaufmann. Jan Hauser and Tsutomu Shimomura who were funded by Sun Microsystems. Julia Menapace who came with Tsutomu. Eric Schmidt of Sun has also agreed to support technical expertise for Tierra in the area of network programming and screen saver technology. Jan Hauser identified the person who has agreed to provide this assistance just before the workshop, and therefore he was not able to attend due to the short notice. His name is Bob Gilligan (bob.gilligan@Eng.sun.com). Similarly, Nathan Myhrvold of Microsoft has agreed to provide similar technical support. Again the Microsoft person was identified too late to be able to attend the workshop. This person has subsequently left Microsoft, so Nathan is looking for a new person.

Security

Tsutomu was not familiar with particular details of the Tierra system, but had a general understanding. He suggested two security issues that are unique to Tierra, and many that are general to network software. The first unique security issue in Tierra derives from the fact that Tierra is a general purpose computer, and that a large network implementation would be a very large general purpose computer, perhaps the largest in the world.

This computational resource could attract the attention of persons who wish to subvert it to do their large scale computations. This presents two security issues. One issue is that the purpose of the network Tierra would be subverted in this way. Given that the network Tierra is viewed as an ecological reserve for digital organisms, in the worst case, this would be equivalent to cutting down the rain forest to plant bananas. The ecology would be destroyed in the process. The other issue is that the subversive computation could be something like code cracking, which many people might object to providing CPU cycles for. This would be like cutting down the rain forest to plant cocaine.

Tsutomu's conception of how this might take place is that the hacker designs a digital organism which would be a superior competitor and at the same time perform the subversive computation. This organism would then be introduced into the reserve where it would proliferate, and even evolve to perform better on its computational task.

Tom objected that domesticated organisms do not make it in the wild. If you plant bananas in the rain forest, they just die. Because the introduced organism would carry the extra burden of performing the subversive computation, it would be at a selective disadvantage. Thus selection would either eliminate these organisms from the community, or would eliminate the computational function from the organisms. In this way the problem would resolve itself and the attempt at subverting the system would fail.

Not everyone accepted the view that Tom put forth. Some people felt that it could be possible for a talented programmer to design an organism that did some applied computation, competed successfully, and was able to maintain these properties in the noisy, evolutionary environment of Tierra, long enough to accomplish the subversive computation. Clearly this would not be an easy task, but it is conceivable that it could be done, and after all, it would be fun to try.

However, Tom suggested that the task could be accomplished by setting up some fake node(s) on the net, and having these nodes flood the reserve with introduced organisms. In this way, the population of these organisms could be maintained in spite of their selective disadvantage.

Tsutomu and Tom disagreed on the viability of subverting the system by simply introducing an engineered organism, but everyone agreed that it could be accomplished by flooding the system. There was a sense that this type of subversion of the system would be very difficult to accomplish, and might not be able to achieve the goal of using the system to accomplish the subversive computation. Even so it could be attempted, and that is a threat in itself. Probably we should develop some monitor tools which could recognize a flooding attack so that defensive actions could be taken if it should happen. Simple introductions would be much more difficult, probably impossible to detect, but some more thought should be given to the matter. Perhaps we could look for the pattern of communications that would be required to collect the data from the distributed computation.

The second security issue related to the information returned by the tping function. Among other things, this function tells us how fast the Tierra virtual machine at a remote node is running, which reflects the activity patterns of the users of the real machine. From this information, it might be possible to infer if the users are at the machine, or to gather some information about their activity patterns. This might be unacceptable to some potential users.

Because the definition of security depends on what is acceptable to the user, it was felt that these two security issues should be discussed in the Tierra documentation so that users could make an educated decision as to whether they consider these to be acceptable risks. It was felt that we do not need to document general network security issues that are not unique to Tierra, although it is also the goal of network Tierra to be as secure as typical network oriented internet programs that exist today.

Actually, the most common fear related to the network Tierra project is that the digital organisms will escape and run wild on the net. However, there was unanimous agreement that this Terminator 2 / Jurassic Park scenario is not a security issue. Nobody at the workshop considered this to be a realistic possibility, because the digital organisms are securely confined within the virtual net of virtual machines.

The following persons and institutions responded: Eduardo Sanchez of the Swiss Federal Institute of Technology (Ecole Polytechnique Federale) in Lausanne Switzerland offered 20 Sparcstations. Lucke Steels and Christophe Wouters of the Free University of Brussells offered 11 Suns. Michael Davis of the University of Delaware offered 23 Suns. Chuck Taylor, Yu Cao and Chris Ferguson of UCLA Biology offered 9 Suns and 7 rs6000s. Dave Cliff and Sharon Groves of Sussex University Cognitive Sciences offered 20 Suns. Santa Fe Institute provided 20 Suns. ATR in Japan provided 20 Suns. We did not use all the machines that were offered, but it was heartening to get such a good response to the request, and we are deeply grateful. We hope that these machines will be available for future tests as the development process continues.

Microsoft has decided to promote its own rpc standards, which are incompatible with existing standards supported by Sun. Therefore it was decided that we should develop our own code for converting data types into a consistent byte ordering for communication between incompatible hardware types.

Roger had originally recommended that we purchase the TCP/IP software provided by the Distinct company, as they intended to release a 32 bit TCP/IP stack with a compatible rcp system. Distinct charges a $100 per CPU run-time license fee for the software that we would ship that incorporates their tools. Given that we intend to sell network Tierra executables for around $50, with the profits going to a rain forest project in Costa Rica, this creates a conflict. However, the Distinct corporation agreed to provide the run-time licenses as a charitable contribution to the rain forest project. The Nature Conservancy agreed to provide Distinct with a tax write-off for the contribution. However, the reason Roger had recommended using the Distinct TCP/IP stack rather than the Windows 95 stack is that Distinct would have a compatible rpc system. In view of the impending rpc wars, and our decision to write our own rpc functions, it was decided to abandon the Distinct deal and go with Windows 95. Tom has sent our apologies and thanks to Distinct, and informed the Nature Conservancy of the decision.

The Windows 95 situation is still not clear. For example, could we work with a 16 bit TCP/IP stack? Will Microsoft provide an SDK for TCP/IP along with Windows 95? We hope that The Microsoft support person will be willing and able to clear up some of these issues for us.

Joseph conferred with the Amiga homeboys on the net and was told that all the necessary software tools for implementing network communications are available. He has subsequently obtained ``AmiTCP'' and installed it on his machine.

Matt explained that the Mac used a very different method of network access than the other platforms. However, subsequent to the workshop, he found that there is a library called GUSI (Grand Unified Sockets Interface) for the Mac that provides a sockets frontend for a lot of the Mac OS calls, effectively making sockets work on the Mac. Matt has the library and it looks reasonably well done and clean to use. The library is freely distributable with our software with some caveats about license inclusion and other matters. The version Matt has is a Beta version for CodeWarrior (the real release works with MPW and Think) that should be released with the CodeWarrior 6 release in May (at which point it will be distributable).

Jeremy said that the Linux version appears to be fully network capable in its present state.

There was agreement to move to a graphic frontend on all platforms, rather than using a text mode frontend as is presently the case. There was much discussion about how this should be organized, because generally with this type of frontend, the main() function is in the frontend code, and main() includes an event loop from which the body of the program is called. The event loop needs to be able to check for events like keystrokes and take control in the case that events need to be handled. After much discussion is was agreed that we can work within the present structure of the Tierra code by an essentially cosmetic change in which the KEYHIT() function in the life() function is renamed to some more generalized thing like CheckEvents(). Then the FEMenu() function will be altered to be passed an argument describing the event, rather than having FEMenu() call FEGetch() to get the keystroke describing the event.

It was pointed out that the information describing the event would have to allow more than a keystroke. In some cases there would need to be a tag describing the type of event, and then some data characterizing the event.

Tom argued that a radically different approach is needed to work with the more creative potentials of evolution, such as its ability to generate the Cambrian explosion of diversity. The approach Tom suggested is to create an environment in which an ecological community of digital organisms can exist and evolve free from human interference. The strategy then is to get out of the way and let evolution work its magic, while at the same time thinking about what are the conditions that can spark a digital analog to the Cambrian explosion, and attempting to engineer these conditions. The network initiative is based on this approach.

Tom got a lot of flack from the audience when he presented a sketch of complexity over time in the evolution of life on Earth, which showed the bulk of complexity increase at the moment of the Cambrian explosion. Melanie Mitchell wanted to know precisely what was meant by the vertical axis, labeled ``complexity''. Tom didn't want to get into a discussion of how to define and measure complexity, but shared his conception of life on Earth as based on hierarchical organization of structures upon structures, through a dozen orders of magnitude of scale from the molecular level up through the ecosystem, the span of scales where evolution exerts its influence.

Several people criticized the graph for placing the bulk of complexity increase in the Cambrian explosion, pointing out that there were other major transitions as well. Tom freely admits that the graph is lousy and needs to be redone to reflect the other major transitions in evolution. Szathmary & Maynard Smith did a nice summary of them in the March 16, 1995 Nature (the article is a teaser for their new book: The Major Transitions in Evolution, by John Maynard Smith and Eors Szathmary. W. H. Freeman: 1995. Pp. 346. $29.95 pbk, we should probably all read the book). Tom will base reworking of the graph on their characterizations. Rephrased in the context of multiple major transitions, Tom's thesis is that most of the complexity generated by evolution has occurred in a series of bursts corresponding to these transitions. The largest of these is the Cambrian explosion. Between these bursts, complexity no doubt continues to increase, but relatively much more slowly.

Melanie stunned Tom by stating that Dan McShea (currently working at SFI) had concluded that evolution does not generate complexity. In subsequent email discussions it was clarified that what Melanie meant to say, and what Dan is stating, is that any claims that ``complexity increases over evolution'' are problematical, and that no empirical evidence has yet been given to establish this. Of course, to give empirical evidence, one has to define ``complexity'', which few evolutionary biologists have done. This is not to say that evolution does not generate complexity, but only that the lack of a complexity measure leaves us without actual relevant empirical evidence.

Kurt described the work with multi-cellular digital organisms based on an instruction set which allows individual digital organisms to parallelize by spawning additional processors. In this work, split and join instructions are added to the set, and the soup is seeded by a creature that splits once, and divides the work of replication between two processors. When these creatures are allowed to evolve, they split further and use as many as 32 processors in their replication. The most highly parallelized solutions show some interesting complexities.

Even so, the parallel solutions are all effectively SIMD style solutions, in which all of the processors execute the same code, but differentiate only to the degree of operating on different data. We are interested in seeing the evolution of differentiation at the level of what code is executed, effectively MIMD style parallelism, which would correspond to the differentiation of cells into different cell types.

It is expected however that this differentiation will not arise in the single node installation of Tierra. The network version of Tierra is being implemented in the hopes of creating an environment which would reward cell differentiation.

Future workshops