[Hplusroadmap] Fwd: Re: [BBF Standards] BioHackathon, or Characterization Challenge

Tue Feb 12 01:56:44 CST 2008

On 12/02/2008, Bryan Bishop <kanzure at gmail.com> wrote:
>
> ----------  Forwarded Message  ----------
>
> Subject: Re: [BBF Standards] BioHackathon, or Characterization Challenge
> Date: Monday 11 February 2008
> From: Bryan Bishop <kanzure at gmail.com>
> To: standards at biobricks.org
>
> On Monday 11 February 2008, Drew Endy wrote:
> > Meanwhile, Bryan, your comment might be well connected to something I
> > was struggling to say...
> >
> > On Feb 11, 2008, at 9:35 PM, Bryan Bishop wrote:
> > > I would like to point out to the list that doubling rate is
> > > strongly linked to development cycle time in terms of biobricks and
> > > the standards. It seems to be nearly equivalent to waiting for the
> > > compiler to finish (except, biobricks are like precompiled
> > > bytecode).
> >
> > As soon as we start working with doubling times below 40 minutes, for
> > many of our systems, the debugging time constant for system
> > performance is limited not by cell growth rate, but rather by the
> > time it takes for protein (and other molecular) levels to rise and
> > fall. Some of the fastest protein production systems around are found
> > in phage, the best of which can produce convert most of E.coli into
> > phage specific proteins by 10-20 minutes post infection.  Faster than
> > this and we have to start thinking carefully about how cell doubling
> > time is driving the reset of system state to ground.
>
> The more the cells proliferate, the more there are cells that are near
> ground state in comparison to whatever it is that we want them to be
> doing. Sounds right to me, because replication necessarily splits the
> resources between the two cells. And on top of this, production rates
> on proteins are necessarily linear (per each cell) because ultimately
> there can only be one protein reading the same sequence of DNA at one
> time (a locking system, if you will), although there are multiple
> ribosomes working on protein folding at a time. So maybe it'd be more
> efficient to insert mRNA ready to go and supply it from our own
> external caches, to control the maximum rate of protein production?
> However, mRNA insertion protocols look complex and seriously involved
> from my end, perhaps we should focus on developing a way to coat mRNA
> with a delicious-looking tag that our bacteria will immediately consume
> no matter whether they are prepped or not in the traditional sense? But
> then we have to be able to control deployed mRNA fragments, i.e. if we
> wanted to flush the system without losing very valuable cell states.
>
> Another quick note - even if we have the ability to synthesize mRNA at
> some reasonable rate, at some point the doubling time of the colonies
> *will* outpace the (static) technological ability to produce mRNA. But
> I don't see cases where you need such large colonies.
>
> > Meanwhile, note that we should be able to deploy active mRNA and
> > protein degradation systems (e.g., ClpX) to push faster reset times
> > independent of the cell growth rate (c/o Bob Sauer et al.).
>
> Looks like you're ahead of me on that one. For flushing, you suggest
> protein degradation systems to do reset times, but what about coating
> the mRNA with something that is both (1) going to be accepted by the
> cells and (2) able to be attracted to a source that the bacteria are
> not, perhaps electrically? This way, we can flush the system, add in
> the protein degradation systems, and keep our bacteria at the same
> time.
>
> So:
> * mRNA coating - to allow quick uptake (prereq - a genome mod?)
> * mRNA tagging - so that an applied current can bring these to the top
> for cleansing (maybe an mRNA filter .. think fishtank-like setup?)
> * Fast mRNA synthesis. Oligo synth protocols seem to take hours??
> ** This looks like a chemistry problem -- so either bring in a chemist
> for this problem or we all develop massive oligo libraries and hope we
> have a relevant sequence ... ugh. Combinatorial storage space, anyone?
> * Protein degradation chemicals (ClpX, etc.)

I am picking up this thread late, so sorry if you have already covered
this. The BIG problem with using RNA in preference to DNA is the
abundance of RNA nucleases in the environment. DNA nucleases exist in
the cell, but are relatively easy to remove or inhibit. RNA nucleases,
however, are present everywhere but the most sterile conditions, which
makes working with RNAs so much harder than working with DNA.

You need to think about synthesizing some engineered RNA that has an
altered backbone that is robust to the action of nucleases. I seem to
remember reading about such kinds of RNA that lack the typical
'sugar-phosphate' backbone, but retain the other important properties
of RNA.

I found something here;

http://nar.oxfordjournals.org/cgi/content/full/25/18/3718

"Enhancement of nuclease resistance of ODNs by replacement of the
phosphodiester group with a phosphorothioate is well established (34
,35 ). This modification generally reduces, however, the affinity of
the ODN for a complementary single-stranded target (36 -39 )."

Not sure what the current 'state of the art' is for making nuclease
resistant RNA mimetics. Otherwise your concept seems sound - you can
(I am sure) persuade bacteria to take up RNA - however, the most
efficient RNA producing machines that we have *are bacteria* - so I am
not sure if the proposal falls down at that stage.

> *
>
> > So, eventually, my guess would be that we want to consider cell
> > doubling times for specific purposes (i.e., production of DNA, cells,
> > or other objects), but otherwise figure out how to decouple the
> > operation of our engineered biological systems from cell doubling
> > time.
>
> I agree re: the importance of decoupling development time from doubling
> time, but this also introduces an interesting coupling of mRNA
> synthesis rates (your dx) in relation to how big a colony you can
> support for massive experiments, but this is a good problem to have.
>
> - Bryan
>
> -------------------------------------------------------
> ________________________________________
> Bryan Bishop
> http://heybryan.org/
> _______________________________________________
> Hplusroadmap mailing list
> Hplusroadmap at heybryan.org
> http://heybryan.org/cgi-bin/mailman/listinfo/hplusroadmap
>

-- 
hello