This is the first post in a series of Journal Clubs. Each time I read a paper about biocomputing, computing, or anything to do with programming cells, I take notes on it on my OpenWetWare bibliography page. I am going to try to follow these cryptic notes with a little post summarizing the paper, and offering my thoughts about it. I hope that this will stimulate a lively discussion about this incredible topic. On with it.

Topic

Programmable Cells: interfacing natural and engineered gene networks, by H. Kobayashi, M. Kaern, M. Araki, K. Chung, T. S. Gardner, C. R. Cantor and J. J. Collins out of Boston University.

Idea

The goal of the paper is to demonstrate a modular architecture for performing one-input, one-output computations inside cells, in this case E. coli bacterial cells. The emphasis of the paper is to demonstrate the modularity of the architecture, and not the complexity of the calculations it can perform.

The architectural framework consists of three modules connected serially together: (Input Processor)-(Logic Module)-(Output Processor). They call these (Sensors)-(Regulators)-(Outputs). Abstractly, the Input Processor is in charge of measuring some external environment variable, and translating it into a biological signal. The Logic Module reads this biological signal, performs the actual computation, then outputs another biological signal, which is read by the Output Processor and translated into a measurable response. A concrete example of this is the cellular SOS response translating a UV light signal into the production of RecA (Input Processor), which degrades a repressor molecule part of a genetic toggle switch causing it to flip (Logic Module) to produce a transcription factor, which activates the synthesis of GFP which can be seen (Output Processor).

To emphasize modularity, the authors discuss the following possibilities:

• Input Processors (2) - the SOS response, and a quorum sensing response
• Output Processors (2) - GFP, and biofilm formation
• Logic Module (1) - a the genetic toggle switch

which is a total of 4 combinations. The genetic toggle switch is a dual repressor system consisting of the classic cI from lambda phage, and lacI from the lac operon, each with each other’s repression regions in front of them. If the toggle switch starts in the cI state (cI produced, and lacI not), then it can be ‘flipped’ into the lacI state by the degradation of cI, by RecA for example.

The authors then report experimental results on the 4 constructions and investigate their sensitivity to input levels, etc. Each construction seemed (to my admittedly untrained eye) to work, and the authors have given strong evidence for the modularity of this architecture, at least with the toggle switch as the Logic Module.

Discussion

I will first say that the authors do a good job of highlighting potential applications of such a circuit including industrial production of proteins that inhibit growth (using the quorum sensing input to turn on the production when the population density is high enough), programming population control by putting a cell death signal as an output, and others. To me they have demonstrated that, with some engineering of the Input and Output modules, they can switch on (or off) certain behaviors using the logic of the toggle switch.

However, I have several problems with the claim of modularity. First of all, more than one of these switches would interfere with each other in the same cell. That is, if there were two switches in a cell, with different Input and Output modules, and one flipped, the other would flip too because they rely on a cellular protein concentration to flip the switch. In computer speak, both switch objects are getting their state from a global variable - the state is not encapsulated in the object. Thus I wouldn’t necessarily call this modular (although I guess it depends on your definition of modular). This global state problem seems to be endemic to biological circuits that we humans engineer. As the authors note themselves:

In many cases, the properties of the system must be optimized rather than
those of individual components.

Cells seem to have figured out to integrate a lot of different signals with at least some protection against interference though. I think this is an area where we need lot’s of improvement.

But this brings up the bigger issue of whether modularity should be the thing that we are striving for at this stage. The above suggests that modularity will come with further fundamental understanding of biology, so why not focus on other architectural principles?

Even more so, this modularity emphasis treats the cell as a programmable circuit board at best. Thus to solve a computational problem, you have to construct a ‘hardware’ circuit that solves that problem. To me this does not mean programmable. I have in mind something more along the lines of an architecture that is composed of a mini-kernel + memory device + language interpreter, all wrapped up into one (for the time being), that you can write code for. To ‘program’ this first simple system would be to do something like write assembly code. Eventually this system could be modularized by the real implementers out there to consist of a stack that is (bottom to top) system devices : kernel : interpreter, much like a modern CPU architecture. Biocomputing ‘languages’ of the future would generate the low level ‘bio-assembly’ code that the first systems would use as its primary language. High-level languages could be built upon the low-level languages, and the history of the modern computer can be played out again, with the biological cell at the bottom rather than the silicon semi-conductor. Obviously there are lots of challenges here.

What we need is the right analogy for such a first ‘monolithic’ system. It doesn’t make sense to take the silicon-computer analogy too literally here - there is no way you could actually implement the hierarchical memory and x86-like instruction set inside a cell right now. Nor should you want to. What is the right thing to think about? I think I have some ideas, but it will take a bit of background legwork for them to be fully developed, and explained to you.

The purpose of this blog is to develop that background.

More Information

Please add a comment to continue this discussion, or edit the my OpenWetWare notes yourself.

Links

• My OpenWetWare Bibliography
• OpenWetWare Notes on this poper]
• This paper on PubMed (free)