Focusing on Fabricators 

From CRN's Timeline for Molecular Nanotechnology page:

Designing a fabricator will not be easy. Mechanochemistry, the formation or breaking of chemical bonds under direct mechanical control, has been demonstrated, but it will take a lot more work to develop the mechanochemical techniques to build diamond and other strong materials. These techniques will require some basic research; however, preliminary work (by Eric Drexler, Robert Freitas, Ralph Merkle, and John Michelsen, for example) shows that there are several different kinds of mechanochemical reactions that should be able to build diamond. Unless all this work is wrong and no other techniques can be discovered, building atomically precise diamondoid shapes will be possible.

The following is a commentary by nanotechnology researcher Ralph Merkle, reprinted from the Foresight Institute website. (Note that Merkle uses 'assembler' to refer to what CRN calls a 'fabricator'.)

Ralph Merkle

The broad goals of nanotechnology—the ability to inexpensively arrange atoms in most of the ways permitted by physical law—are now widely accepted, but we need more. It is not enough to agree that heavier than air flight is possible, nor is it sufficient to believe that some design based on rockets can reach the moon, nor does the abstract realization that mass can be converted to energy change the course of history. We need to move to the next step: the Wright Brothers, the Apollo Program, the Manhattan Project—we need to translate abstract agreement into a focused and funded project.

This raises the obvious question: focused on what?

Nanosystems gave us a persuasive feasibility argument for assemblers, but didn't give us a design for a specific assembler. For every fundamental design problem, Nanosystems gave us several feasible solutions—but never picked one specific solution. Indeed, one of the main thrusts was that we could have confidence that assemblers were feasible precisely because there were many solutions to every problem—it's difficult to be absolutely certain that a specific solution will work, but when there are many possible solutions available it's almost certain one of them will work.

We have seen continued work on specific aspects of assembler design but we haven't seen a complete design. Such a design (and accompanying analysis) is feasible today, but a complete design will require the work of a team of people for some years. We need to explore the space of possible designs, analyze at least some designs in full detail, and then use those designs as a point of focus for further development. We can start today, but have not.

The major consequence of this failure is continued delay, much of which will be caused by continued confusion about "what is an assembler." While we know that all the fundamental problems can be solved, we don't have a single design or embodiment that selects a specific solution for each problem and integrates those specific solutions into a single unified system. Perhaps more seriously, there is the fog and uncertainty created by mental confusion and misunderstanding. People have a hard time grasping complex arguments and abstract conclusions, and when we are hearing new ideas for the first time it's very easy to get confused. Flight to the moon was thought impossible because "there is no air to push against" in the vacuum of space. Airplane wings push against air, propellers push against air, helicopter blades push against air—surely the proposed space rockets were meant to push against air? But there is no air in space! So can our experience with familiar things mislead us when we consider fundamentally new ideas.

A project with many people must have a clear, detailed, and comprehensive description of both the goal and how to achieve it. We need at least one design for an assembler with all the kinks worked out, all the irritating little design issues settled, all the potential sticking points resolved. Without this, any effort to build an assembler will deteriorate into chaos and confusion as the people involved find themselves working at cross purposes—possibly without even realizing it. If we want to build a heavier-than-air flying machine, and one person designs the blades for a helicopter and another works out the wings of an airplane while a third says we should propel the device by throwing sticks of dynamite out the rear and exploding them, the result will be chaos.

Right now, the detail that we can achieve in a system design is limited by the fact that serious design efforts have so far been limited to one or perhaps two people. We could greatly increase the detail of the design by increasing the number of people (provided they are the right people). Half a dozen to a dozen people, properly coordinated, would be a great improvement over the present situation, and would start to provide us with system designs that had a level of detail that would give us greater collective clarity in understanding the goal and a greater ability to determine the developmental pathways for reaching it.

Besides pursuing designs in greater depth and detail, we should also examine designs that differ radically in their approach and assumptions—we can explore the design space seeking designs that are (for example) easier to build. Consider the Analytical Engine, designed by Babbage in the 1830's. The single most important intellectual development of the 20th century, Babbage's design was never built nor was there any systematic exploration of possible alternatives.

Looking back with the advantage of 20-20 hindsight, we can see what Babbage and the rest of the world missed: relays. Relays were known in the 1830's, and were widely deployed in the 1840's for use in telegraphy. Had Babbage and others explored the design space for "Analytical Engines," they might have realized that a relay-based computer was relatively easy to build and quite practical. But they didn't, and so missed an opportunity of historic magnitude.

Let's not miss another opportunity.

Thank you, Mr. Merkle. For more information, please see Foresight Institute Update 51.