Introduction
Synthetic Biology has become a hot topic in the world of finance. The evolution of the field to create solutions and real products can also be understood as a turning point: where multi-talented teams could deliver engineered organisms faster, without high-risk investments and much more results. These products and engineering success could be explained by the application of engineering principles as the focus of synthetic biology.
However, to create optimal frugal biofoundries will need good engineering practices from diverse fields (e.g., software, mechanical, electronic, synthetic biology), all of them integrated in a cohesive stack, that we call the BioStack. We also understand that all these outputs should be generated using the Open Source flag, where people around the world could use, modify, commercialize and contribute to all these different fronts.
Project
The project defined three technical teams:
- Synthetic Biology
- Software
- Hardware
By having all these different engineering cycles running together in our project, we will try to abstract this as a tree, generally separated by branches organized by an engineering team, that are connected by some deliverables.
Synthetic Biology Goals (Wetware)
The synthetic biology team defined as the main objective is to build genetic modified organisms that could be used for frugal protein production. The first step was defining the chassis for organism engineering. The choice selected was two chassis that have a well-defined transport system for exporting proteins from the cell media, eliminating steps for cell lysis in protein purification protocols.
The first one selected is Bacillus subtilis KO7 strain, created for high-expression and modified with 7 exoproteases knocked-out from the genome. The idea for using this strain was actually from Dan Zeigler, Director of the Bacillus Genetic Stock Center at Ohio State University (see more in the Human Practices > Part III > Biology). The second one is Pichia pastoris, a strain that Open Science Network Community lab already have experience using when they created the Open Yeast Collection for the FreeGenes project.
Now with two chassis selected, the team also defined three main experiments with one DBTL cycle each one:
- Design, build and test a modular shuttle vector for high protein expression for Bacillus subtilis but could also be compatible with E. coli for better building steps. Integrated in this experiment, using enzymes codon optimized using 4 different strategies:
- Saccharomyces cerevisiae for building and testing using the OpenYeast expression vector.
- Codon optimized for Bacillus subtilis strain PY79 (the variant above KO7).
- Codon optimized for Bacillus subtilis strain KO7.
- Codon optimized for Bacillus subtilis strain PY79, where specific genes are highly expressed during stress under nutrient limiting media. Literature (Welch et al. 2009) shows codon optimization based on codon frequencies related to these genes could improve protein production.
- Codon optimize for E. coli and Bacillus subtilis strain. PY79
- Design, build and test a plasmid of parts, a concept created by the Design Team to build and test in a high-throughput manner all different Bacillus subtilis secretion tags with one step Golden Gate assembly protocol.
- Enzymes codon optimized for Pichia pastoris and Saccharomyces cerevisiae..
Plasmid of parts
We designed the Bacillus subtilis Secretion Tags (Bsub SecTag) library plasmids with high fidelity Golden Gate overhangs that were compatible with FreeGenes' E. coli Protein expression toolkit, and its 'Proclo' extension of the MoClo assembly standard while maintaining high predicted assembly fidelity with the original MoClo transcription unit overhangs.
Then later, we designed the rest of our Bacillus toolkit to be compatible and interoperable as much as possible with the plasmid backbone cloning (BaClo) assembly standard from the Open Yeast Collection. However, after we'd already synthesized the library plasmids, we tested predicted ligation fidelity of the ProClo and BaClo overhangs together using the NEB Ligation Fidelity Viewer, and found that the the ProClo and the BaClo overhangs don't work well together (predicted assembly efficiency <50%) and thus can't really be developed on as a unified set.
We learned two actionable things from this cycle that informs the next rounds of our wetware development. First, we learned that to work with the currently existing OYC and PET to do, for instance, rapid prototyping of frugal enzyme manufacturing in yeast, it will be necessary to leverage more advanced wetware design tricks in order to keep the incompatible overhang sets separate.We used this knowledge to inform the design of Bacillus wetware parts with BtgZI-BsaI part type conversion and dropout cassettes.
And second, having identified an important compatibility problem with two of the most potentially useful FreeGenes wetware toolkits, we learned there will be a need to re-design both collections with a unified assembly standard to enable the biotechnology commons to actually be easy to use and contribute designs to.
Software
The Software team started the project with a defined scope of projects, that was later refined in the notebooks and actions that were delivered (access our repositories) and tested through our iGEM season. We made three full DBTL cycles compromise of each one of:
- A toolkit of modular scripts for automating the design of genetic parts, most of them compromise of laborious or complex tasks for Wetware team. We called them the Friendzymes toolkit.
- An educational kit of notebooks with tutorials to create and use some already build features very commonly used during the Synthetic Biology Design step. We emphasize documentation so people from the community could easily adapt, learn and distribute.
- Atomized scripts that could be integrated in pipelines for automation of DBTL cycles. We make scripts compatible with Github Actions, a free to use Continuous Integration tool inside Github.
Friendzymes Toolkit
The first DBTL cycle of the Software Team was to develop a list of tools to help the Design Team to create genetic parts in a seamless way. It was defined that our work should focus on building tools for our codon optimization strategies, resolving problematic region of coding region sequences, automatic annotating problems inside a sequence, simulating golden gate reactions, search for Bacillus subtilis terminators in annotated sequences, checking if IDT could synthesize our parts using their API, and other small tools. All these tools were implemented, tested, optimized, validated and used for building all our parts, devices and plasmids. We’re very proud to say that if you take a look at our parts, you’re also seeing our software tools.
Friendzymes Cookbook
After using the Friendzymes Toolkit successfully in the design of our parts, we understand that sharing these tools with the community is the natural next step. But we found that understanding Go language and how to use the Poly library (see more in the Software > Friendzymes Cookbook) will be a great barrier to share this easily with the community. So we created the Friendzymes Cookbook, a list of Jupyter Notebooks to teach people about Poly and with a lot of our already ready to use scripts, designed from the beginning to be compatible with free-to-use Google Colaboratory. The notebooks were validated by sharing them with the UTPrimers, a Brazilian Design League Team that used the notebooks to their own design of parts.
Friendzymes Actions
The high-throughput demand of biofoundries and scalability necessary aren’t suitable for Jupyter Notebooks. To tackle this we decided to use Github Actions, a free-to-use feature inside Github allowing projects, mostly open-source, to use this process manager to automate tasks inside the repository. We implemented, documented and tested our collection of actions and also created some examples that summarize each feature.
Hardware
Some problems were overcome in the hardware building process. One of them occurred in the procedure of building the bioreactor inspired by Sebastian Cocioba's design (see Integrated Human Practices > Part III > Hardware). As a first option, we consider incorporating an ON / OFF temperature control developed through a relay, we had some problems keeping 37ºC constant because this control was not so precise. Then we built the circuit (schematized in the Hardware page), using low-cost electronic components, such as transistors and optodevices, and we were able to implement a Proportional Temperature Control. It was possible to reduce the temperature control error to more or less 0.1 to 0.2% of 37ºC, meaning more control and accuracy for the system.
