Trumpet is an operating system for simple and robust cell-free biocomputing | Hacker News Reader

Trumpet is an operating system for simple and robust cell-free biocomputing

nature.com

45 pointsaelnona20 comments

> It is likely that the future of biocomputing hardware and software will likely include a combination of all three technologies [19]: live cell, enzyme-free, and enzymatic logic gates.

This prediction has a bunch of fun implications for security:

* Viruses and malware for such computers will also have a physical virus stage

* Tradeoffs between DNA and traditional methods for data storage

* A possible arms race between obfuscating and detecting unusual retrotranscriptases

> Tradeoffs between DNA and traditional methods for data storage

Wonder how badly it could go if the data storage container is ruptured while against someone's body?

DNA cross contamination could be interesting, unlikely to be in any kind of good way.

> Wonder how badly it could go if the data storage container is ruptured while against someone's body?

Nothing, really. Your body is good at fighting that sort of thing, because it's literally happening every second of every day with billions of bacteria and environmental DNA. Even specialized organisms have a rather tough time getting by all the defenses.

For example, there are zero human-infecting raw-DNA pathogens.

Cool, that makes sense. :)

Could at least some bio computers be hacked to print ebola viruses?

Yes, but that's essentially like hacking a CPM machine to emit a Microsoft Word macro virus. It's not that it wouldn't work, it's that it's a lot of extra effort for no particular reason except maybe bragging rights.

If the goal is to use a bio computer to compromise a biological system, a more likely pathway would be to get the programmable system to construct something more like a prion (an auto-catalyzing protein complex) rather than faffing about with all the extra complexity and layers of indirection of an infectious virus.

If your target bio system is a plant rather than an animal, constructing a viroid might be worth the effort.

From someone who has reconsistuted viruses from synthetic DNA - it’s WAY easier than working with prions, or even viroids for that matter. The fact they package themselves and release themselves, while being formed of genetic sequence, is SUPER nice. Any bio computer doing sequence manipulation will probably find it way easier to use a virus-like replicating “malware”

I guess it depends on whether the replicator is supposed to replicate on the bio computer platform or on a biological platform.

The biocomputing platform needs to not only assemble the sequence but also assemble the (or at least "a") protein encapsulation for initial delivery to an organism.

> for no particular reason except maybe bragging rights.

Hmmmm. If we're talking about actually wanting to infect someone with an engineered virus, then using something with sequences widely attributed to some other group could be used as cover.

Along the lines of "they were infected by a Russian variant of ebola". Or any other group, false flag operation type of thing.

Hopefully this doesn't become an actual thing. :(

> Wonder how badly it could go if the data storage container is ruptured while against someone's body?

TL;DR: pretty much zero unless you're immunocompromised

The price tag of the broken equipment and bacterial infections are probably the biggest concerns.

Genetic information is like software. It doesn't do anything unless it's in a compatible environment. Eukaryotic cells like those in plants, animals, fungi are delicate. Viruses which can write DNA into them without killing them have to be complicated, which makes the viruses delicate. Being this delicate means work with these cells and viruses can be very expensive.

Why try to use a multi-Xeon server rack with fiber links when all you need is a cluster of 5 Raspberry Pis and a bare bones router? The latter is way cheaper.

For the same reasons, well-understood bacterial models like tame E. Coli strains are popular in biocomputing [1]. Slime molds [2][3] are also popular, and they're even famously good at pathfinding.

Your coworkers, however, might be annoyed that you broke the biocomputer again.

[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6421265/

[2] https://link.springer.com/referenceworkentry/10.1007/978-3-6...

[3] https://royalsocietypublishing.org/doi/10.1098/rsta.2014.021...

> * A possible arms race between obfuscating and detecting unusual retrotranscriptases

Why, exactly?

Using living cells as a read/write storage medium also makes them a target for malware. It's not limited to ransomware and classics, but also fun new possibilities [1]. Figuring out how to implement W^X should be a top research priority.

[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4270005/

I don’t see how that has to do with obfuscating unusual reverse transcriptases, though. There are plenty of (if not more) DNA based transformation methods, and those enzymes are sufficiently widespread that it’s not unusual to find them nor is it particularly hard because of the structures

I think you're looking at this from a nuts and bolts perspective rather than a broader security mindset.

The incentives and goals for malware are what matter here. The first steps for satisfying those are always achieving undetected write and execution. In this context, RTs and everything else are just means to that end.

The broader security mindset is identifying the technologies that are most probably used in a situation where you need read and write. For example, in computer security, you wouldn't worry about a air-gapped UNIX server being infected by an online windows worm. Undetected write and execution are not enabled by RT, like, at all. Synthesis (write) is pretty much a DNA technology, and the only time that a RT is used is for proper viral packaging (lentiviral transformation, mostly). But there is also not really a need to obstruficate because there are tons of completely valid uses for lentriviral vectors. In fact, there are open source RT plasmids available because they can also be used for things like production of open source COVID tests (for example, during COVID I deposited this expression vector under open terms https://www.addgene.org/165556/ ). If you really want to get into the weeds, there are retrotranscriptases that are naturally expressed in humans: good luck with false positive hits on detection.

More broadly, in biology, there isn't really a thing as undetectable execution, because there are physical molecules floating around, and furthermore there are trillions of natural self-executing blobs in an arms race with the ribosomal world. Detecting execution, as technology gets better, is more of a problem of privacy than technology.

Undetected write is more important, but it is also important to identify the particular technologies that actually matter. It's not RTs, nor is it Cas9, nor is a lot of the things that people typically point out on hackernews, either.

My understanding is that they are picking a genome (in whole or in part synthetic / designed by them), a set of starting enzymes or transcription factors or the DNA sequence of those (not sure) (also in whole or in part synthetic), then running a computation by letting DNA transcription happen for some number of cycles, and finally read the output by some signaling protein like fluorescence that will either be present or absent depending on how you designed the initial conditions.

To me, Trumpet sounds more like a compiler or circuit/program synthesizer than an operating system, since my understanding is you have some circuit in mind and the goal is to find a good genome (and/or the enzymes, not super sure yet) that can implement it. This means finding enzymes that will accurately promote or block transcription at a target location. And also checking against potential problems as the computation/reaction progresses since in a deep circuit depth you would presumably have many more kinds of things floating around that could interfere. I didn't see any mention on the circuit efficiency here, like how many base pairs per gate as # of gates increases, which I would guess would get larger faster than linear.

They mention the signal amplification of many genomes being transcribed which is really neat (like error correction). Though makes me wonder if the output signal has a defined or expected duration of stability. If it is stable forever, it is like a fixed point or attractor, but I suspect unless under much greater design or control, things would change. And what is the latency of these gates?

With cell-free, it seems plausible to design from-scratch genomes using a database of known proteins and that could be really cool. And funny to think about applying evolutionary search to determine the fittest genome for the job. From there we go to unicellular and then up to multicellular!

What is an operating system at its core but an abstraction layer between software and the underlying hardware.

If your software speaks boolean logic and TRUMPET provides the layer between that and the underlying proteins then I'm happy to bless it with the title "Operating System".

In either case, some cool stuff. Can't wait to install Linux on the mold in my forgotten coffee cups!

> We have demonstrated the use of Trumpet to build all universal Boolean logic gates. We have also built a web-based platform for designing Trumpet gates and created a primitive processor by networking several gates as a proof-of-principle for future development.

Sounds super cool. The website doesn't seem to be hosted on the web but they provide a ZIP download in the supplemental information section: https://static-content.springer.com/esm/art%3A10.1038%2Fs414...

It's a bunch of Python files. No docs on how to get started but the filenames are reasonably semantic.

Edit: the paper says it's supposed to be hosted at https://trumpet.bio/ but that's not working for me

Edit again: http://trumpet.bio/ works (just not https)

Hmm, looks like DNA debugger with breakpoints and step by step running.

Trumpet winsock

Reply on news.ycombinator.com