\documentstyle[12pt]{article}

\flushbottom
\textheight 9in
\textwidth 6.5in
\textfloatsep 30pt plus 3pt minus 6pt
\parskip 7.5pt plus 1pt minus 1pt
\oddsidemargin 0in
\evensidemargin 0in
\topmargin 0in
\headheight 0in
\headsep 0in

% Hanging Paragraph with no parskip
\def\XPNS{\vspace{7.5pt}\par\begingroup\parskip 0pt\parindent 0in\everypar{\hangindent .3in}}
\def\eXPNS{\par\endgroup}

\begin{document}
\thispagestyle{empty}

\begin{center}
{\LARGE {\bf First Tierra Workshop Report}}
\end{center}

\section{When and Where}

The Tierra Workshop took place at the Santa Fe Institute on March 24-26, 1995.

\section{Who}

The workshop was attended by the following persons:

Tom Ray\\
ATR Human Information Processing Research Laboratories\\
2-2 Hikaridai Seika-cho Soraku-gun\\
Kyoto 619-02 Japan\\
81-7749-5-1063 (phone), 81-7749-5-1008 (fax)\\
ray@hip.atr.co.jp ray@santafe.edu ray@udel.edu\\
http://www.hip.atr.co.jp/\verb$~$ray\\
unix, DOS\\

Jeremy Bruestle\\
11825 16th Ave. NW\\
Rice, MN 56367\\
612-393-2213\\
bruestle@stcloud.polaristel.net\\
PC, DOS, Linux\\

Roger Gouin\\
4632 N. Rockcliff Road\\
Tucson, AZ 85715\\
phone (602)749-1785\\
rgouin@indirect.com\\
PC, Windows\\

Joseph F. Hart\\
3008 Madison Avenue\\
Niagara Falls, N.Y.\\
Phone:  (716) 284-1871\\
Amiga\\
\begin{verbatim}
___________________________________________________________________
                  |         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 ***
===================================================================
\end{verbatim}

Matt Jones\\
Programmer Analyst II\\
Psychology Department\\
1504 Psychology\\
UC Santa Barbara\\
Santa Barbara, CA 93106\\
Phone: (805)893-4818\\
Fax: (805)893-4303\\
mjones@condor.psych.ucsb.edu\\
Mac\\

Kurt Thearling\\
Pilot Software\\
1 Canal Park\\
Cambridge, MA 02141\\
(617) 374-1117\\
(617) 374-5555 fax\\
(800) 950-PILOT x1117 toll-free\\
kurt@santafe.edu\\
CM5\\

Jan Hauser\\
Sun Microsystems Inc.\\
2550 Garcia Ave\\
MS UMIL06-07\\
Mountain View, CA 94043-1100\\
Day (408) 276-3454\\
Hm. (408) 353-4727\\
Jan.Hauser@EBay.Sun.COM\\
Unix\\

Tsutomu Shimomura\\
San Diego Supercomputer Center\\
P.O. Box 85608\\
San Diego, CA 92186-9784\\
tsutomu@sdsc.edu\\
security\\

Julia Menapace\\
210 Clayton St.\\
San Francisco, CA 94117\\
juliam@well.com\\
Mac, security\\

Charles Ofria\\
Kellogg Lab 106-38 California Institute of Technology\\
Pasadena, CA 91125\\
charles@altair.krl.caltech.edu\\
Avida/Artificial Life\\

Titus Brown\\
Kellogg Lab 106-38 California Institute of Technology\\
Pasadena, CA 91125\\
brown@krl.caltech.edu\\
Avida/UNIX/DOS/Networking/X graphics (TK/TCL)\\

This report was drafted by Tom Ray, and revised in light of the
comments offered by Jeremy Bruestle, Roger Gouin, Joseph Hart,
Matt Jones, Kurt Thearling, Jan Hauser, Charles Ofria, and
Titus Brown.

All of the participants were funded by the Tierra Workshop from
Santa Fe Institute funds, except:

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.

The main topics discussed were: security, the status of ports of Tierra
to the different platforms, the options for implementing the network
version on the various platforms, how to generalize the Tierra
interface across platforms, how to generalize the socket calls across
platforms, the Avida system.

\section{Security}

The discussions began with the security issue.  Tsutomu started the
discussion with some general comments about the philosophy of security.
He suggested that first we must define what the limits of the system are,
i.e. what we want to accomplish and what we want to disallow.  Then
there are in effect three levels of the process:  a) What do you want to
accomplish (security policy).  b) What do you think the implemented system
does (design and code).  c) What does the system really do (testing and
``assurance'').  The reason for `c' is that sometimes if is very difficult
to prove that a system really does what you think it should do.

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.

\section{A network experiment}

In preparation for the workshop, Tom solicited the use of CPUs from
a number of institutions around the world, to run a moderate sized
network Tierra during the workshop.  The main idea was to have
something running that Tsutomu could experiment with as a part of
his security review.  As it turned out, Tsutomu did not want to do
this during the workshop.  However, it provided an opportunity to
experiment with setting up a moderate sized network, which had not
been done before.

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.

\section{The rain forest connection}

Tom made a brief presentation to explain the connection between
the network Tierra project and a rain forest conservation project
in Costa Rica.  Tom has been involved in the development of the
National Parks system in Costa Rica since 1977.  These efforts
have contributed to the creation of a fairly large area of
protected forests in north-central Costa Rica.  The present
phase of the rain forest project aims to bring a few more
unprotected areas under protection, and to work towards the
long-term stability of the protected areas by developing
economic activities connected with the natural areas.

The Tierra license agreement states that the source code can be
freely distributed, but not the executables.  The Tierra executables
are available on floppy disk for \$50.  For the network version of
Tierra, the profits from the sale of the executables will be
contributed to the rain forest project in Costa Rica, through
the Nature Conservancy.  All of the members of the Tierra development
group have agreed to this arrangement, and they will receive no funds
from the sale of Tierra.

\section{The status of ports of Tierra to the different platforms}

Each of the five developers, Roger (Windows), Matt (Mac), Jeremy
(DOS, Linux), Kurt (CM5), and Joseph (Amiga) reported on the status of
the port to their platform.  In essence, Tierra has been fully ported to
all the relevant platforms.  In the course of discussion, it was
decided to stop supporting the DOS and CM5 platforms.  Jeremy will
then maintain the Linux platform, and Kurt will look into porting to
some other parallel machines.  While we have new ports to Windows,
Mac, Linux, and Amiga, at the time of the workshop, they still existed
as five versions modified from a common source code.  After the workshop,
the original source code was passed among the developers and the five
versions were integrated into a single version of the source code that
compiles down to the different platforms.

\section{The options for implementing the network version on the
various platforms}

The most problematic platform for network implementation appears to be
the Microsoft platform.  At present, we are not aware of any software
tools that provide a 32 bit TCP/IP stack (we should note here that we
were at a bit of a handicap since our technical support person from
Microsoft could not be present).  This functionality is supposed to be
included in Windows 95 when it is released, but it was not yet available
at the time of the workshop (though a beta version has been subsequently
released and Roger and Tom have obtained copies).

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.

\section{How to generalize the Tierra interface across platforms}

It was agreed that the Tierra frontend should be separated from the
Tierra process, and should actually be a separate process.  Tierra and
the frontend would communicate by whatever mechanism is appropriate to
the platform (such as sockets).  Matt pointed out that the Mac is
not a true multi-tasking system, so it will not be possible to have 
the frontend as a separate process, but that he can work within the
framework by replacing socket calls with function calls.

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.

\section{How to generalize the socket calls across platforms}

Because the details of how the network is accessed varies widely
between platforms, we need to abstract the network calls to Tierra
functions that conditionally compile.  For example, the sendto()
socket call should be replaced with something like Tsendto().
Tsendto() would contain the \#ifdefs necessary for it to compile
to the relevant functions on each platform.  It was also agreed
that the part of Tierra that checks for incoming messages should
be split off as a separate process in order to speed up the Tierra
process itself.

\section{The Avida system}

Charles and Titus presented a summary of a large body of work that has
been done with the Avida system at CalTech.  The Avida system is a
derivative of the Tierra system, with perhaps the biggest difference
being that the digital organisms are mapped into a two dimensional
grid, where one creature occupies each cell of the grid, and the
genomes of the creatures exist in a space orthogonal to the 2D grid.

The Avida group has been using Avida to study the physics of evolution.
Tom expressed the opinion (reiterated here) that the work of the Avida
group is the most beautiful work done with a Tierra-like system.
For those not at the workshop, look to the following publications for
more information:

C. Adami, ``Learning and Complexity in Genetic Auto-Adaptive Systems''
          Physica D 80 (1995)154.

C. Adami, ``Self-Organized Criticality in Living Systems''
          Caltech preprint 1994, submitted to Phys. Lett. A

C. Adami, ``On Modeling Life'', Artificial Life 1 (1994)428;
           Proc. ``Artificial Life IV'', (MIT Press) 1994, p. 269

C. Adami and C.T. Brown, ``Evolutionary Learning in the 2D Artificial 
             Life System `Avida' '', 
           Proc. ``Artificial Life IV'', (MIT Press) 1994, p. 377

C. Adami, C.T. Brown, and M. Haggerty,  ``Abundance Distributions 
           in Artificial Life and Stochastic Models: "Age and Area" 
           revisited''; 3rd European Conference on Artificial Life, 
           June 4-6, 1995, Grenada, Spain (to appear) 

C. Adami and C. Ofria, ``Speciation in Single-Stranded Self-Replicating Code'' 
           Caltech preprint (1995)

\section{Jan's presentation}

Jan Hauser presented Sun's project DOE and the Object Management Groups
(OMG) CORBA technology.  There may be some future interest in using
DOE/CORBA as a ``rendezvous'' and management device for all the world-wide
Tierra users.  OMG/CORBA is designed specifically for the design, creation,
debugging and administration of (Globally) Distributed, Heterogeneous,
Object Oriented Applications

The current network Tierra prototype also has performance problems on
unix because of polling problems.  Jan suggested a two-process
architecture that should overcome this problem.  This general solutions
has been under consideration and will likely be adopted for the unix
version.

\section{Tom \& Kurt's lecture}

At the end of the first day Tom \& Kurt presented an open lecture to
the Santa Fe Institute community which was well attended.  Tom
presented as him main theme, the argument that the Tierra system
offers the possibility of working with the more creative potentials
of evolution: the ability to generate species and to generate
complexity.  Whereas all previous work with evolution, from the
domestication of plants and animals to the fields of genetic
algorithms have essentially worked at the level of managing evolution
within the species, through breeding of captive populations.

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.

\section{Future workshops}

The Santa Fe Institute has agreed to support the Tierra workshop as
an annual event.

\section{Signed by}

Tom Ray, Jeremy Bruestle, Roger Gouin, Joseph Hart, Matt Jones,
Kurt Thearling, Jan Hauser, Charles Ofria, and Titus Brown

\end{document}
