Self-replication
From Biohack
2008-04-07 review: over at Slashdot.
"If you put something back together enough times, soon enough you'll have enough for two of them."
Hierarchy of self-reppers
This is all subject to change. There should be a hierarchy of self-reppers such that we can begin making something of a first order, and then move up the hierarchy to more powerful and interesting machines.
- SR0
- State.
- Billions of different states?
- State.
- SR1
- Self-modification. (state changing)
- Oscillator?
- Self-modification. (state changing)
- SR2
- Self-disassembly. (an internal state change that prevents further state changes)
- A computer that could unhook its energy source.
- 'Unfabbing'.
- Self-disassembly. (an internal state change that prevents further state changes)
- SR3
- Disassembly/re-assembly. (an internal state change that prevents further state changes, but that also happens to reboot the system)
- Basically this is implying that cells are repeating highly compressed spans of evolutionary history each time they do self-replication. Each time they replicate, they are repeating aspects of their evolutionary history.
- Basically this is implying that cells are repeating highly compressed spans of evolutionary history each time they do self-replication. Each time they replicate, they are repeating aspects of their evolutionary history.
- Disassembly/re-assembly. (an internal state change that prevents further state changes, but that also happens to reboot the system)
- SR4
- Self-replication: ability to build a seed at no cost to the ability of the parent to continue replication.
- Resource management.
- Self-replication: ability to build a seed at no cost to the ability of the parent to continue replication.
Another attempt at the self-repper hierarchy
- Self-reproduction
- Can make self/non-self
- Can make all required components
- No, no organism does this. Not even the autotrophs.
- Can make all required components
- Can make self/non-self
RepRap
- Needs to be able to make its own electronic circuitry.
- Semiconductor manufacturing.
- Needs to be able to make all of the required components to build a semiconductor fab.
- CVD chambers, chemical etchants, photolithography, mechanical parts required to move all of the machinery, to automate the entire process, ...
- Note how this would require pre-built electronic motors in the first place.
- Electronic motors do not need semiconductor tech, of course.
- Note how this would require pre-built electronic motors in the first place.
- CVD chambers, chemical etchants, photolithography, mechanical parts required to move all of the machinery, to automate the entire process, ...
- Does not need to be very precise -- milimeter si fab tech would be acceptable.
- Needs to be able to make all of the required components to build a semiconductor fab.
- I have figured out how to make electronic circuitry with simple transistors with a printer and inkjet cartridge. Is this enough for RepRap to do interesting stuff?
- Semiconductor manufacturing.
Rap's Law of Inanimate Reproduction
"If you take something apart and put it back together enough times, eventually you will have two of them."
Freitas-Merkle Map of the Kinematic Replicator Design Space
src.
- Productive non-replicators
- Can make other things. See RepRap.
- Nonproductive replicators
- Can only make itself.
- Interesting philosophical problems here - i.e., what is 'self'? Can it make the components required to make itself? Aren't these components nonself? Is it not from other things that you are ultimately made?
- Can only make itself.
- Productive replicators
- Can produce self & non-self.
Preparation for self-replication
2008-03-13: Given sufficient preparation, self-replication can occur. It all depends on how much preparation you do of the matter and energy. If the matter and energy is provided in the proper form, then there is nothing left but some interaction to occur such that the matter and energy is arranged in such a way as to provide for that same reaction to take place again (some sort of "self-preserving reaction"). There was once a man who was able to do self-replication with LEGOs. He had a lego robot that was able to move around a course and use its positioners to assemble the pieces of itself into the same design. -- Kanzure 09:59, 13 March 2008 (CDT)
Abstract/analytical von Neumann probe design
2008-03-22: It should be possible to make the specifications for the von Neumann probe in an abstract sense, not based off of any materials, such that you can then go off to experiment with materials that meet the specifications and do a massive search of the available-material-space to come up with the solution. This is kind of like the inverse RNA folding problem where you provide the folded structure, and the program then uses analytical methods to go off to search for the sequence of nucleotides that would fold into that result (perhaps through reverse heuristics or just by a general formula that leads to the discrete nucleotide combinations directly). So what would the components be of a design of this nature? There would have to be (1) matter/energy collection, (2) matter/energy processing, and (3) matter/energy application, such that #3 can make the machinery for #1. If this was to be hand-drawn and diagrammed, it would have a specific shape and look sort of messy with lots of requirements floating back and forth. Once this design is achieved, then what? -- Kanzure 09:18, 22 March 2008 (CDT)
The "contractory phase" design approach
See this image: [1]. in von Neumann's original kinematic self-replicator design, there is an arm standing in front of a shelf of components. The arm takes the component and lays it out somewhere nearby, and then takes another component and snaps it in place, repeating this process until all components are assembled. And so if we have a 'number of parts' we can then go back and jot down all required machinery to make that particular part (to process the raw mineral-resources and put it on the shelf), and then if we want to do good then we have to optimize all of that machinery to use the same resources and be made from the same arm-manipulator.
In the first design phase, we might have three components that the arm manipulator (fabricator) is made from. So, the arm must be able to take those three parts and snap them together to make a functional arm. This has been shown in a video before on the internet.
The next step is to break those components down even further. So, this is what we call a "break-up phase", and in each break-up phase, the components are broken down into their components, a method of assembling them into the one original component is given (i.e., another manipulator arm, perhaps). Then, we loop through as many "break-up phases" as possible until we have the minerals and resources required. And all the way back up to the top we have a method of processing the minerals and putting them into the component forms, all the way up to the arm-manipulator component in the last step (the original part where we started in this thought exercise).
When done with all of the break-up phases, you have a list of all of the machines required to assemble the raw materials into their next component forms, which are then combined into the next components, all the way up until the last three components of the arm are assembled together to make the manipulator arm itself. Now all of the tools in the mean time -- the ones that were processing the raw components and assembling the components to the components to the components to make the arm -- can be made from the same materials. Note that the machine to process sand does not have to be made from sand, but rather it can be made from, say, aluminum, which is what another machine might deal with (and that machine might be made from sand). So all of these "in the mean time" machines have to be simplified and combined into one "mega machine" that can do all of those steps. If you can combine all of the machines into a single machine, and this single machine is equivalent to the arm-fabricator that you were making in the first place, then you have a self-replicator.
So, in conclusion: for(i=0;i< total number of components at this phase; i++) { break down all of the components at this phase; design a machien to put the components together; ). I need to represent this in a more computational fashion. This pseudocode represents the method of designing it, mentally, not the actual construction process (all of these terms can get easily confused for each other. Hard to separate them. We need more vocabularies to deal with these issues).
Note the differences between:
- mineral-processing subsystems --- processes the minerals as input
- Note that the "sand-processing subsystem" need not be made out of sand. The "sand-processing subsystem" needs to be made out of X mineral where there exists in the design "X-processing subsystem" which, again, is not necessarily made out of X, but it has to be made out of something like "X" that eventually makes it full circle back to sand.
- mineral-relying subsystems (are made out of the mineral)
- mineral-actively-relying subsystems (in their day-to-day function, they actively need the mineral)
- Al-dependent replication
- Read this as: the function "replicate" requires aluminum.
The graph based approach
Recursive tree that loops back on itself, a directed cyclic graph. The vertices are packages, the edges are functionality being used. Throw in tons of packages and functionality into a giant pot, poke it with a stick and fish out the closed-loop graphs, these will be self-replicators. If we have to, we could do simulations where we enumerate the entire functionality of various minerals and have those included in the pot. Our computer programs would search for directed graphs within the pot (this should be possible in comp sci).
Terminology update: streams are run-time capabilities/requirements, packages are build-time, packages can provide streams.
In the case where we have to simulate chemical reactions, we have to also include the specifications for doing certain reactions. For example, the requirements for doing a certain organic chemical reaction type might require a certain type of chamber, which requires certain types of resources, which, again, would require some other resources. So when you program in a new type of reaction, you have to specify that its inclusion must necessarily add terms to the simulation, where ideally you can minimize the number of terms included (so before you run the simulation, you check all similiar terms and select for those, and then you start fishing for your replicator graphs).
2008-03-23: Uh, isn't this graph-based approach equivalent to searching for the Hamiltonian cycle? So there's no guarantee that the problem is solvable by "putting everything into a giant pot".
The overall dependency loop must depend on itself (but not only itself -- other things (like humans) should be able to make it). All matter or energy in the design must be theoretically capable of having been processed by the system in the first place (by itself).
Putting everything into a giant pot for simulation and finding the directed cyclic subgraphs (the replicators)
Wouldn't you have to put all materials, resources, streams, packages, etc. into a giant pot? This would be like skdb, with socialized engineering knowledge detailing what we know how to do, and then specifying what is required in order to do it (the materials required for the chamber, the sort of functionality required to make the chamber for a specific reaction, etc.). Where possible, self-dependency is to be desired, in other words the entire database should be super-saturated so that everything relies on everything else to some extent. These dependency loops must be able to make it full-circle back to themselves, so that partA requires partB which requires part{N} which requires partA in turn. Interestingly enough, there's probably a set of such replicators that can't be made by humans, but that satisfy all of the requirements, but I bet that if we do find anything, it will be something that we are able to construct.
So the software simulation required to search for the subgraphs that qualify as self-replicators: what sort of data format is required, to what extent can it be based off of skdb? There are so many variables for each item and unit. Perhaps we need to bring in a programmer to brainstorm ideas (Ryan Patterson?). All of the different tools and methods that engineers know would have to be slammed into a giant database and be self-referential, what engineer has that sort of knowledge already? Very few. And as you add information into the database, you start to realize there's more variables, so whatever the system is, it has to allow for new variables to be added, and the overall "equation" might have "isolation islands" where variables are important to each other, but only to a certain extent, where these islands have variables that can be optimized and the overall island is used in the final search for a KSRM, although this significantly restricts possibility space (good for (1) limiting the amount of computation and (2) bad because KSRMs might not involve 'isolation islands' of variable dependency in isolated packages, where all packages must rely on others. In fact, I am sure that there will be no isolation-islands since all packages must be able to make each other). I am having trouble imagining what this software will look like, and what will the database look like? Will it be just like APT, except with each module/package defining variables it needs and uses? And then finding ways to hook up different modules to each other with units that 'convert' variables from one form to another. Obviously all of these variables are unpredictable from first principles, but the design of the overall system can be made so that fundamental code changes do not have to be made. The 'simulation' would take the entire database and connect all of the parts/packages together and recursively explore all possible combinations, searching for a directed cyclical subgraph within the entire mess. For example, electricity generator package -> Sterling engine -> some other modules -> ability to make the electricity generator (functional run-time requirements during 'replication' functionality of the project). In my opinion, this is just a special subset of the overall functionality that should be possible with skdb. This wouldn't quite be "unit testing", but rather "project synthesis" where a set of abstract requirements are met (and in this case, it's simply the requirements of a directed cyclical graph). Unit testing would occur, however, to make sure that each module does what it is supposed to do. A good test of the system would be to make up three fake components (A, B, C) where A makes B, B makes C, C makes A, and then see if it can find this graph in a pot of maybe 100 other automatically generated packages, maybe with some bigger dependency loops but with possible routes of simplification (i.e., A -> B -> C -> D where B -> C and B -> D, the software should find A -> B -> D, not A -> B -> C -> D).
Combinatorial testing of all of the packages in skdb does not sound like a good idea for skdb project synthesis, but on the other hand we know that all matter and all energy can be converted into each other, so any two packages of functionality can be converted into each other with the lego-like placement of energy converters between two packages. So, if A -> B can be made with an energy convert (A -> converter -> B), and then if B -> C is needed, and if B -> C doesn't have enough energy to work because of entropy production in the A->B converter, then that would not be a valid connection to make in the synthesis-software.
It is worth noting that APT is notoriously bad at resolving dependency issues. Isn't that what we are working with here, dependency issues? Actually, it has bad dependency resolution since it doesn't know what the user wants, but in our case, we can test out different possible resolutions in an attempt to get everything working.
Minimal Cell Project approach
Take a look at the minimal cell project approach. If we can effectively model streams and packages in the minimal cell scenario, then surely we can come up with a similar system in mechanical terms.
Cheating a little bit and requiring humans
But since humans self-replicate, adding in a self-replicating component isn't really cheating (it's just symbiosis or something). If we can give enough instructions for a person to completely make a machine, and if the machine then carries human DNA and can spawn the seeds somewhere else, and in that other location gives enough tools and resources for the resultantly generated human to make another machine again, then we can say that it is self-replicating (as long as we can insure that the human will be able to do everything necessary).
Eventually we may not need to have the entire human, but rather just a way to get an organism to make the replicator-entity itself. This would mean that the organism would assemble all of the parts together. So far humans are intelligent, yes, but they require intense training to get them up to the point where they understand why they would have to build the replicator for their bodies/children etc. Not good. And how would you use such a replicator anyway, if you were wanting to build orbital habitats or something? In general, you wouldn't.
Sipper excerpt
Langton’s self-replicating structure is a loop constructed in a two-dimensional, eight- state, ve-neighbor cellular space and is based on one of Codd’s elements, known as a periodic emitter [16] (Figure 5). The 86-cell loop is basically a closed data path, consisting of a string of core cells in state 1, surrounded by sheath cells in state 2 (this latter state is represented by dots in Figure 5). Data paths are capable of transmitting data in the form of signals, which are packets of two cotraveling states: the signal state itself (state 4, 5, 6, or 7) followed by the state 0. The signals contained within the loop cycle through it, composing the instructions for replication, that is, the arti cial genome. As each such signal encounters the arm junction it is duplicated, with one copy propagating back around the loop again and the other copy propagating down the arm, where it is translated as an instruction when it reaches the end of the arm. In executing the instructions the arm extends itself and folds, ultimately resulting in a daughter loop, also containing the genome needed to replicate.
The self-replicating structures described up to this point were all designed by hand, a difficult and time-consuming process. Lohn and Reggia [46, 47] and Lohn [45] used genetic algorithms [52, 53] to discover automatically automata rules that govern emergent self-replicating processes. Given dynamically evolving automata, one of the most difficult tasks is that of identifying effective fitness functions for self-replicating structures. Lohn and Reggia were able to solve the fitness problem, thereby demonstrating that self-replicating structures can be evolved. Chou and Reggia [14] asked whether self-replication can come about spontaneously. They demonstrated the possibility of creating a CA universe—a “primordial soup”—in which self-replicating structures are not inoculated ab initio but rather emerge in a spontaneous manner (cf. Koza’s work—Section 3). Their CA model incorporates a number of interesting features, including (a) the division of the cellular state into substates (bit elds), which facilitates the emergence of self-replication (Morita and Imai [55–57] presented a similar idea—the partitioned CA), (b) support of extended replication, in which the offspring structure may differ in size from its parent, and (c) the ability to handle collisions between structures, a situation that in previous models usually led to utter chaos.
Using Sipper's vocabulary, I am mostly interested in a von Neumann kinematic model of self-replication (or even self-reproduction).
Loose notes
2008-03-31: Just as semiconductors are useful for computation, some nameless material here is useful for self-replication. Semiconductors guide electrons in a specific way, the electrons and whether or not something has an electron represents on/off. What if the electrons could guide the substrate (the silicon, but not necessarily silicon, there exist other options like graphene)? This would be field-effect fabrication. See field-effect transistors [2]. In FETs, you can control the size and shape of the electric field, and hence the conductivity of a certain channel that electrons can travel down. Could the field effect be the only process that is needed for self-replication? Can the field effect be used to move new components into place? To use transistors as a way of physically/mechanically fabricating objects? They can already control the flow of electrons; what might this mean if they can physically control which electrons go where in a nanoscopic path? Could this be used to control the creation of specific nanochemical structures? But there is nothing that says we need necessarily focus on such small scales.
Aren't there some kooks on the internet interested in field-effect propulsion? [3]. I think I was looking at the electrostatic gliders a while back, using the ion flows over surfaces or somethng, but I realized that to get past the gravitational energy you need way too many volts or amps, but I do not remember looking at this for nanoscale systems.
Self-replication can be done with any materials, all that is required is "sufficient preparation".
Mechanical, chemical, bio energy can all be converted into each other since they are all fundamentally relying on the same subsystems, so ideally there is some commonality that we can use, perhaps an intersection of mechatronics, mechanics, chem, bio, subatomic particle physics, ...
Also note that biology already uses nanotechnology for self-replication, but in the case of organisms, the DNA itself is the nanotechnology and the code replicates itself into functional components, a direct chemical conversion from specifications to functionality, although it seems to lose the ability to have "clear functionality" for the ability to evolve ... an interesting tradeoff, but irrelevant for the type of self-replicating machines that are needed in this case.
Aha, how about just (1) piezoelectric effect and (2) field effect? I need somebody to shoot my idea down: self-replicating machine with (1) the piezoelectric effect (like in speakers and piezo motors) and (2) the field-effect (like in transistors, semiconductors, etc., the HUMO-LUMO gap). The piezos on parent would move the transistors of child into place. The transistors on parent would provide an electric aversion to piezos 'connecting'/stabilizing in that area (but the places where they are supposed to be, sure).
This really just needs to be a self-replicating AFM or scanning probe lithography (see also AFM lithography) tip. It has to be able to store its own program for designing itself, it has to have a relatively large chamber or something so that it can be stabilized with respect to what it is drawing on, and it has to be able to do enough layers, even if the electronics can all be done on the same layer, yes. It has to be able to make that large box that it rests in or something. If it can make the tip and the electronics, how would it then make the framework for resting the piezos in and so on?
Has anybody ever done a solid-state AFM system? One where the AFM tip was drawn in as a micromechanical device itself, and then the only thing connecting it to the macroscopic world was the power-electronics and data signaling for transmission/reception?
What if self-replication turns out to be a blackswan?
It is important to note the entire new field of software and mathematics that would have to be bruteforced in order to do a search over the functionality-space to find those directed cyclic graphs within the databases. We would have to make the database on our own and painstainkgly ensure standards and make sure everything is using the same types, variables, parameter standards, and on and on and on, then we have to do extensive testing of the software all the way up until the point where we try to generate a possible design for a kinetic self-replicating machine. Not good. Generally not good. Usually I claim that the reason that we need self-replicating machines is for making orbital supercomputers and neurofarms so that we can do massive automated combinatorial testing. But is this that really necessary? Should supercomputers be avoided as a blackswan? At least until we get self-replication. But it is important to not falsely classify self-replication as a blackswan when in reality it's more of a requirement to go study mathematics and ways of approaching this problem with heuristics -- if it's equivalent to making a scientific discovery, it may not be possible to bruteforce this, but on the other hand it seems that we have a pretty good idea for going about it (but it's a lifetime of work to add that much data -- unless we can automate it a bit by having others contribute to the project in some way: can we make the project work such that we don't have to tell them we're making a self-replicator, while also letting them find functional relevance for making their own projects from combined parts?). If self-replication does turn out to be a blackswan, then I'd need to reformulate my ideas so that combinatorial testing of neurogenetic modifications is not required. How would you sandbox neural modifications? You don't just immediately commit a change. You'd have to experiment with a human-managable number of mice or rats, and how much can you extract from a population of that size? Not much, really. Or you could do simulations on a supercomputer, but we just said to treat supercomputers as a blackswan too. So how do we do neuroengineering without killing oursleves in the process, and without self-replication for testing? Self-replication has to be a whiteswan. Surely. Maybe there's a mathematical proof that self-replication is a whiteswan?
See also
- Exponential assembly
- "Exponential growth of large self-reproducing machine systems," by Klaus S. Lackner and C. H. Wendt, Mathl. Comput. Modelling Vol. 21, No. 10, pages 55-81, 1995.
- Moshe Sipper's artificial self-rep page
- Quines - comp sci definition of self-replication
- smn theory, Church-Turing hypothesis, Kleene fixed-point theorem, ...
