Creepy crawlies 2

The gray goo scenario is not an immediate threat. Evolution of nanomachines can be prevented, and gray goo replicators can simply not be designed, as long as everybody agrees to those rules. If that were that, we could prevent the gray goo scenario forever. But not everybody will agree. Some, having loudly agreed in public, will quietly break the rules in private. But real live gray goo won't become possible very soon.

There are lots of "interesting" lesser threats.

At the time of the Pontiac rebellion in 1763, Sir Jeffrey Amherst, the Commander-in-Chief of the British forces in North America, wrote to Colonel Henry Bouquet: 'Could it not be contrived to send smallpox among these disaffected tribes of Indians? We must use every stratagem in our power to reduce them.' The colonel replied: 'I will try to inoculate the [Native American tribe] with some blankets that may fall in their hands, and take care not to get the disease myself.' Smallpox decimated the Native Americans, who had never been exposed to the disease before and had no immunity.

Silent Weapon: Smallpox and Biological Warfare by Colette Flight writing for bbc.co.uk/history

What we can expect in the near term is biological warfare, evolving along lines similar to biological warfare today, and with similar motives. If we are interested in a future world that is benign, we can try to remove the incentives for biological warfare, so that there is as little of it as possible. This is an area where I myself can offer no particular insight. There have been many many different manifestations of human evil in recent decades and centuries. I would like to think I could entrust politicians and diplomats to go about its prevention, but they are usually the ones who start the next one. This is a thorny problem involving culture clashes, economics, religion, and many other topics beyond the scope of this blog.

Another possibility is to educate ourselves about the possible range of weapons, in the hopes of designing effective defenses. This is a much more technically tractable problem, and it's one of the reasons I work for Nanorex. Our software can help people to explore the space of possible threats and defenses more quickly, and to create an active research literature.

Is an active literature a good idea? Would it not be an enabler for those who wish to do harm? Should it not be suppressed or at least discouraged?

This is like the relinquishment question. If the bad guys have an active research literature and the good guys don't, then the first bad guy attack could reduce the good guys to a state where they could never again hope to meaningfully protect themselves.

Ideally, thoroughly effective defenses would be deployed everywhere, long before the first offensive weapons appear. I hope it goes that way. If we're not so lucky, there may turn out to be such a diversity of possible offensive weapons that "effective defenses" aren't practical.

Lessons from software development

I've been a software engineer for ten years now. Software engineers build and maintain very complex systems, so complex that no single engineer can grasp the whole thing in all its details all at once. Coming from electrical engineering, I found that a humbling new experience.

Software engineering looks a particular way, because bits are much much cheaper than transistors. Software products are generally much more complex than hardware products. So software engineering has a richer set of tools for managing complexity than hardware engineering has.

Testing is hugely important. Engineers test products, and the more testing they do earlier, the fewer bugs they need to fix later. If you've got a system that's incomprehensibly complex, you can still understand how to test it.

Modularity is an example of information hiding. Designs are made up of individually comprehensible pieces or modules. Each piece has complexity inside and simplicity outside. The simple outside part, the interface, determines how that piece works with its neighbors.

nanoENGINEER-1, alpha 7 release

The Nanorex team is proud to announce the release of nanoENGINEER-1 Alpha 7, the seventh major release of nanoENGINEER-1. This is the first major release since Alpha 6 was announced on August 17, 2005. Alpha 7 has many improvements and new features.

Undo/Redo

Alpha 7 now includes a new Undo/Redo system making it easy to undo accidental changes to models.

Simulator/Minimizer Improvements

The nanoENGINEER-1 simulator and minimizer have undergone major revisions since Alpha 6. A7 introduces our new and improved molecular force field. We have expanded the list of parameters from our initial testing set to include more atoms and bond types from among the main group elements. It is our intent to have all possible bond types for the first three rows of the main group of the periodic table (B-F, Al-Cl, Ga-Br, and H with all chemically possible combinations of single, double, and triple bonding) accounted for with the completion of the simulator work, except for bond torsion terms, which are planned for Alpha 8. Once this initial set is complete, we will welcome requests for other bond types.

To ensure the accuracy of the minimizer and, consequently, our new molecular force field model, we are developing tests which compare the minimizer output to quantum mechanical results performed at the same high level of theory (B3LYP/6-31+G(d,p)) as the force field itself. These tests have been run on a variety of small structures to cover as many of the force field parameters as possible.

Improved Modeling Interface

Making nanoENGINEER-1 easy to learn and use is one of our highest priorities. With Alpha 7, building models has never been easier and more intuitive. Chemists using commercial molecular modeling programs such as Chem3D, Spartan or Accelrys will find nanoENGINEER-1 a breeze and enjoy its ability to manipulate large chemical species just as easily as small molecules. Mechanical engineers experienced with traditional CAD programs like SolidWorks or Pro/ENGINEER will feel right at home creating and viewing models even though their knowledge of chemistry may be limited.

Wiki-based Help

A new Wiki web site for nanoENGINEER-1 hosts a set of on-line Help pages that can be accessed by pressing the F1 Key while the cursor is hovering over objects in the nanoENGINEER-1 user interface. Users are able (and encouraged) to create a Wiki user account and add or edit the Help pages themselves. We anticipate that over time the Wiki will become an invaluable resource for users of nanoENGINEER-1.

Improved Graphics

Graphics quality and POV-Ray support has been improved significantly. We’ve included animation when switching between views, specular highlighting and improvements to the general graphics and lighting control system that give nanoENGINEER-1 a professional luster it lacked in previous versions.

Nano-Hive Support

nanoENGINEER-1 can serve as a general purpose molecular modeling front-end to Nano-Hive, a nanospace simulator written by Brian Helfrich. Working together, nanoENGINEER-1 allows users to interactively define, calculate and visualize 2D electrostatic potential (ESP) images of molecular models. To see an example of this new capability, check out the ESP Image jig in the nanoENGINEER-1 Gallery.

Mac OS X

Alpha 7 does not yet work on Intel-based Mac systems. We are working on this and hope to support Intel-based Mac systems in the coming weeks. We also just discovered a problem plotting nanoENGINEER-1 simulation trace files using GNUplot on Mac OS X. We will be fixing this problem in the next day or two and posting a new MacOS install package in the Download Area.

Creepy crawlies

When Eric Drexler published Engines of Creation, he included a section on run-away nanotech replicators. The notion is that if there are replicators running around that can use almost anything as feedstock, they buzz through the biosphere converting everything to copies of themselves, leaving behind an ocean of replicators. This is called the "gray goo scenario".

This idea has been popularized by Bill Joy and Michael Crichton and, along with the toxicity of present-day nanoparticles, is considered by many to be one of the grave risks we face in pursuing nanotechnology. Bill Joy's article in Wired recommends that we (the U.S.? the developed nations? Bill and the mouse in his pocket?) simply refrain from developing the technology.

There's a problem: we might refrain, but others won't. The research is difficult but not impossible. Those who pursue the research would be the people who didn't agree to refrain from development, and this dangerous new technology would end up in the hands of those we'd be most fearful of having it.

Drexler and the Foresight Institute, seeking to educate the public and help reason win out over panic, have struggled with these worries for years now. He has argued that building a free-ranging eat-anything replicator is a very difficult engineering problem, comparable to building a car that can forage in the woods for fuel when it runs out of gasoline. Nobody designs a foraging car by accident. A gray-goo replicator may not be possible at all, and if it is possible, it will be the design work of many years.

A dangerous replicator might evolve from nanomachines that started out safe. Many troublesome viruses probably started out as mutations of innocent snippets of DNA. Human-designed nanomachines should not be permitted to evolve. There has been keen interest in nanofactories in recent years, where the instructions are clearly separate from the assembly machinery (what Ralph Merkle calls a broadcast architecture, and computer folks call a SIMD architecture). The instructions are only put to use when the human user decides to push the button to make stuff happen. Autonomous self-replication can not occur, and therefore evolution cannot occur.

Another way to prevent evolution is to ensure that every mutation is fatal. Suppose the replicator's only copy of its blueprint is encrypted, and replication requires decrypting the blueprint each time. If you change one bit or one character in an encrypted document and try to decrypt it, the whole thing becomes meaningless garbage. Any change to the encrypted blueprint will turn the decryption into garbage, and the machine won't be able to build anything.

Finally, there are different ways to pull the plug. One is to stop supplying the energy required for replication. Another is to require tha replication depend upon some exotic "vitamin" available only in a controlled environment.

Scanning probe microscopy

SPM is a collection of microscopy techniques (of which the first was the scanning tunneling microscope or STM) that permit the imaging of individual atoms. The resolution of the microscopes is not limited by diffraction, but only by the size of the probe-sample interaction volume, which can be as small as a few picometres. The interaction can be used to modify the sample to create small structures.

The STM is an ingenious gadget, invented in 1981 at IBM Zurich. An atomically sharp probe is positioned above a sample; the gap is typically on the order of a nanometer. The probe and the sample are both electrically conductive. A voltage is applied between the probe and the sample. Electrons tunnel across the gap.



It turns out that the tunneling current is very strongly dependent upon the gap distance. So you build a servomechanism that moves the probe up and down in the Z direction, to keep the gap distance constant by keeping the tunneling current constant. Next, you scan the probe in the X and Y directions, tracking out a raster pattern like the one on your television screen. By looking at the Z position information from the servomechanism, you end up with a function Z = f(X, Y) and when you plot that function, or use it to color the pixels on a computer screen, you get pretty pictures of atoms.



The STM is so conceptually simple that it's possible to build one as a hobbyist.

A few years after the STM, the AFM or atomic force microscope was invented. With this device, the interaction between the probe (this time on the end of a cantilever) and sample is not an electric current flow. Instead it is a force due to the Van der Waals interaction. The force can be measured using piezoelectric strain gages built into the cantilever, or using a reflected laser beam to measure deflection of the cantilever.



You would have hoped that these microscopes would have been useful in pushing atoms around as well as seeing them. To a limited extent they are, but not so useful that you can start to build molecular machines with them. Darn.

Molecular electronics

Over the past few years there has been a lot of fascinating work in molecular electronics. Because of the success of digital logic implemented in VLSI over the past several decades, molecular electronics researchers have focused most of their attention on implementing digital circuits using logic gates.

Early work included the identification of a molecular rectifier or diode, a device that allows electrical current to pass one way but not the other. Arranging diodes in a crossbar arrangement is a major step toward the implementation of complex logic circuits. Additional pieces required to make it practical include nanoscale wires, inverters, and amplifiers, and maybe a flip-flop.



Carbon nanotubes can have different chiralities, which give different electrical properties. Some chiralities give conduction so that the nanotube functions as a wire. Other chiralities give semiconductor behavior, introducing the possibility that a nanotube may be useful as a carbon transistor.

There was some very interesting work done by HP and UCLA in January 2002, basically a way to build a rectangular array of north-south and east-west wires, and connect them by fuses that could be selectively blown. That permits a lot of flexibility in wiring up circuits, which you need to do anything interesting. I haven't heard much more about the HP-UCLA work since 2002, though, and I wonder if they've hit some kind of stumbling block. Their work was based on rotaxanes and catenanes.

There is more to say on this topic, and it will merit another posting one of these days.

More molecular machines in nature

Painless blog posting: plug "molecular machine" into Google Scholar, and cut-and-paste whatever comes out! I'm not quite that lazy, I looked at them to see if they were reasonably complete, and weren't of such narrow interest that only three people in the world would want to read them.

• Information-theoretical considerations of molecular machines
  
• The ribosome
  
• Blood coagulation
  
• Bacteriorhodopsin
  
• Viral capsid self-assembly
  

Two molecular machines combined

The first combination of two molecular machines has been claimed by Kazushi Kinbara at the University of Tokyo, Japan. The first piece is a light-driven actuator which twists a double bond one way in UV light, and the other way in visible light, causing a pliers-like pair of pieces to hinge closed and open. The ends of the pliers connect to a couple of flippers. By pulsing the light correctly, one can presumably get the flippers to kick, and make the thing swim around in a liquid.


Click for larger image

According to the article, research labs have produced a profusion of interesting molecular machines, but none by itself does anything complex enough to be really useful or extensible. The innovation here is supposed to be the combination of multiple machines. I'm not sure that flapping flippers is much more useful behavior than any of the individual machines would perform. It would be interesting Kinbara had found some kind of general approach by which different submachines could be built into large assemblies, but there is no evidence for that in the articles I could find. Kinbara evidently sees the value of that as a goal, and guesses that large assemblies are about five years out.