Storing Data in DNA [pdf] | Hacker News Reader

Storing Data in DNA [pdf]

homes.cs.washington.edu

60 pointsChuckMcM17 comments

If this kind of work interests you, I'd also recommending reading Yaniv Erlich and Dina Zielinski's DNA fountain paper (which just came out in Science). They've done some really nice work on error correction, and they also understand the sequencing technology limitations, etc. Of course this is all really expensive to read and write now, but sequencing technology is only getting cheaper and cheaper. Here' the link to the updated preprint: http://biorxiv.org/content/biorxiv/early/2016/12/04/074237.f...

I had to share this, there have been a couple of news stories about storing information in DNA and personally I find the topic really fascinating. I suspect however that it is impractical to store data in a medium which requires DNA sequencing to extract, (very long 'time to recover' in the disaster management parlance) but its a fascinating idea in general.

But there are lots of natural techniques to copy dna and repair it when it fails to copy properly so durability should be solid.

Lots of thoughts on this. It's a really interesting area, and the paper doesn't gloss over the challenges. Important caveat right at the top though:

"Progress in DNA storage has been rapid: in 1999, the state- of-the-art in DNA-based storage was encoding and recovering a 23 character message [7]; in 2013, researchers successfully recovered a 739 kB message"

That's not a terribly large message. The difficulty of synthesizing large tracts of DNA reliably is a major bottleneck. It was a huge accomplishment when a full, relatively small genome (1x10^6 bases, humans are ~3x10^9) was synthesized in 2010 [1]. Granted for storage purposes, fully synthetic DNA may not be required, but it's still hard to assemble pre-existing DNA into very large constructs.

Sequencing the message itself is on its surface not too hard, I think a current-gen high throughput sequencer can read up to 2 trillion bases in a single run. It's not super fast (1-2d turnaround), or random access though, and the random access nature is one of the innovations in the paper. Still some sequencing approaches are a little quicker it should be possible to leverage modern sequencing tech to make this suitable for archive-level purposes.

Other thoughts on the paper: they have a cool take on how to avoid errors (Huffman code), and take advantage of highly parallel DNA synthesis approaches by properly segmenting the data they want to store into useful chunks. You still have to avoid errors in synthesis and replication for DNA storage, and they take steps to mitigate risk there.

Anyway, cool paper, if anyone knows more about the state of the art of long-DNA strand synthesis I'd love to hear about it!

[1]: http://science.sciencemag.org/content/329/5987/52

Microsoft was reporting storing a movie and operating system and some other stuff : http://thehackernews.com/2017/03/dna-data-storage.html

very cool, didn't know about this, thanks!

I would not be so sure whether it is really necessary or advantagious to have very long DNA strands as information medium. Long DNA strands are very hard to handle under many conditions (we only got into the range of 1 million bp reads last week, it probably wont be in the near future that we get some at a reasonable fraction) and provide limitations like increased replication timing (Polymerase work in the order of 1kbp per minute, else you would need many origins of replication). Shorter fragments (~1kbp) are much easier to handle and sequence and can be reached by almost random access through primers attached to fishing beads.

Very much agreed, but then you're stuck with ensuring all the pieces of DNA are faithfully transmitted through the next replication. Essentially you're proposing having tons of 1kbp chromosomes, so you're shifting the problem from having a hard to handle piece of DNA (the longer the harder it is to have it not sheer/break/otherwise get damaged) to faithfully moving around lots of tiny pieces of DNA, and maybe depending on the system needing to guarantee not losing one of them entirely, or ensuring that the copy number of each one doesn't deviate too much from all the others, or both.

I think yours is probably the right way, though.

Can we embed this data in dormant DNA in existing life? Can I hide my PGP keys in the DNA of my houseplant?

You could certainly do it in an E. coli bacteria tomorrow. You'd need on the low end 128 or 256 bits of coding capacity, which you should be able to get out of a few thousand base pairs according to their scheme. Not super easy, but I've made strands that long using only oligos and with a little tinkering you could correct any errors. Now tie that DNA to an antibacterial-resistance gene, stick it in a bacteria, and you can selectively grow only PGP-bacteria nearly indefinitely (with some minor caveats, but yeah).

Houseplants are substantially harder for a variety of biochemical reasons including having multiple chromosomes, and more difficult selection protocols, but yeah that should be possible too and made somewhat easier by CRISPR.

Of course you could, but now that we know you plan to hide you PGP keys in your plants, you're hit by the old "security-by-obscurity" fallacy. :/

Just xor it with a one time pad, encoded in a fern.

Yes, you can. Depending on the organism type, it will shed that dna after some generations though - organisms with useless dna chunks have a slight evolutionary disadvantage.

I imagine impementing some kind of additional checks - e.g. special genes that kill organisms wih a bad checksum of the stored data.

Supposedly, assuming that the sequence doesn't harm the organism (or that the organism doesn't alter the sequence). Bacillus spores can remain dormant for decades, if not centuries, and date palms have been grown from millenia-old embryos.

Reminds me of the Corgi in Cowboy Bebop

What I never understand in these studies is why they always want to go for single base resolution immediately. Sequencing and writing is so expensive because any error you make is a real problem. If instead, every bit was encoded by a default oligomer of 5 times the same base, you could live with much higher error rates. You would loose density but still achieve multiple orders of magnitude over current storage solutions.

In addition to mitigating errors in copying as you've highlighted, there is also the possibility that some stretch of bases in your message would have some deleterious effect on the organism. Thus, you would need to include some kind of redundancy into your code so that a bit could be represented in several different ways. The computer that encoded the message could then try to optimize the message so that it would be maximally amenable to storage.

I wonder what their read/write speeds were.

Reply on news.ycombinator.com