Community Conversations: Behind the Scenes with Seb Mondet, Senior Software Engineer at TQ Tezos
Hello everyone and welcome to the fourth installment of Community Conversations! As the community manager for Blokhaus I am on a journey to interview builders, creatives, and community members from around the Tezos ecosystem. Our guest today is Seb Mondet, Senior Software Engineer at TQ Tezos.
TQ Tezos is an organization focused on building enterprise-grade infrastructure for the Tezos ecosystem. They offer technical support to many projects and have created useful tools like OpenMinter and Homebase.
Seb is a senior developer in the Tezos ecosystem, a member of the merge-team, and has helped with work on a variety of projects including TZIPs, Flextesa, TZComet, and SmartPy. SmartPy is an intuitive and powerful smart contract development platform for Tezos; TZComet is an explorer/editor/validator/visualizer for Tezos contract metadata.
Check out the interview below!
—
What got you involved in blockchain technology?
I mean, I have been following it since the beginning as a hobby. I really enjoy the novelty of the censorship resistance. Back in 2010, when WikiLeaks exposed the war crimes and so on — to see them being censored, everybody cutting access to the donations, and then watching them switch to Bitcoin as a means of evading the censorship — that was interesting. However, proof of work never felt like the right thing. I don’t think it’s that good for making things distributed or even censorship resistant because it’s hard to move your infrastructure and you cannot be reactive. Then, Tezos showed up on the OCaml mailing lists. I had been using OCaml for a long time and I ended up looking into Tezos. I liked the idea of proof of stake; Tezos also had formal governance and formal verification which were really neat features.
What made you choose Python to focus on with the SmartPy project?
The SmartPy project itself was already started when I joined. It was asking for help from TQ at the time and I also knew the guy doing it. Even though I didn’t make the choice myself, it was still very good in the end. SmartPy is a meta programming language. So, you’re writing programs that generate programs that are themselves the contracts. The actual language you generate is something closer to Michelson and closer to a functional programming language with data types.
Why would someone choose Python, as opposed to Rust or another programming language?
Rust is extremely low level. It asks you to think about things that you should not care about for 99% of the problems. Why put the burden on your brain when some automatic tool could be doing it? Python is very popular. Many people can come in and say, “oh, I know Python so I can just get started and write smart contracts.” However, the programming language, in the end, is not that important; it’s just a matter of what gets people started with building smart contracts and serves as a good hook.
Now that you’ve had a decent amount of experience working in the Tezos ecosystem, are there any other aspects that you find particularly fascinating?
The formal methods part. Of course, that was one of the stated goals of the Tezos project from the beginning. Formal methods, in general, is the idea of proving mathematical theorems about software to ensure that there is no bug in any possible exchange. Basically, it helps remove even more human mistakes from the process. The really cool part is that, after seeing a lot of development in the area for the past couple decades, we have started seeing formal methods actually being utilized with Tezos. Smart contracts are the perfect use case for those kinds of methods because there are small programs that are extremely risky. Putting a lot of effort into formal methods has a high reward, because you remove a lot of risk.
Can you tell me a bit about your work on other projects?
Sure. TZComet comes from the interoperability standards that we were working on. They are standards that are written to make people agree on how to make interfaces for smart contracts or how to expose metadata about smart contracts. TZComet started as a web app to verify that you obey the standards. We also made an editor, so that, if you have an error, you can actually try to fix it there. Now, it also has a token viewer for NFTs and general tokens.
Why does Tezos use Michelson instead of a more common language like Python, Rust, etc.?
The native language of the protocol has to be custom to better fit what’s meant to be run on the blockchain. However, even though we’ve seen Michelson slowly evolve, it’s not impossible that, one day, somebody will propose a completely different programming language. It’s not easy because writing a new protocol is also writing the migration between the previous protocol and the current one. If you change, fundamentally, the programming language, you need a way to run all the previous contracts that were already established on-chain, but it’s possible.
So, does Tezos have an advantage when it comes to the programming language compared to something like Ethereum and the EVM, considering the programming language was built with certain additional applications in mind?
I think Ethereum’s main limitation is that they have no governance. The collaboration is kind of forced on everybody and decisions are made from the top. They need to switch from Proof of Work to Proof of Stake which is such a fundamental change — in the end, the programming language is the least of their problems.
How does on-chain governance make your life as a programmer easier?
The nice thing about governance is that it puts less pressure on people and it spreads out the responsibility. It’s a collaborative effort. Everyone ends up contributing and checking over everything to make sure it all works. Also, the timing and schedule of the upgrades is clear and well-known.
What about when it comes to the freedom of development, considering the fact that anyone is able to propose changes to the protocol?
Yeah, so far it’s been more beneficial to collaborate together but it’s always possible for people to go the other way and that serves as a good safety net. Sometimes, people talk about being unhappy, and the good thing is — well, it’s all open source. If you want to change something, do it. If you want to do something that the core team doesn’t want to do then you can put it up to the bakers to decide whether they agree with you or not. It’s all very formalized and it greatly improves the decision making process.
What are some of the reasons why you would recommend Tezos to a developer?
It’s a solid PoS protocol that has been running for almost three years. It’s sustainable, better distributed, and it works well. The governance also makes it a good bet. In the future there likely won’t be a big fork. The community’s also really focused on safety and security, which is a good base to have when you’re building something on top of something else
Thank you very much for the interview!
