Q&A with Mehdi Bechiri, Alluvial's Director of Site Reliability Engineering (SRE)

Mehdi discusses his interest in decentralized technologies, why SRE Engineering is important across sectors, lessons learned from mining, and more.

Q&A with Mehdi Bechiri, Alluvial

Q: Hi Mehdi! Tell us about your background, and your journey to working in the crypto space. When did the idea of decentralized technology become a part of your interests?

Hi! I've been working in traditional finance IT for more than 10 years, ranging from inter-bank settlement systems to Corporate & Investment Banking, so I was evolving in finance already. When it comes to crypto, I first heard about Bitcoin in 2013 when its all-time high (ATH) was ~$1k (which seems like an eternity ago, now that I think about it). The idea of DigiCash—brought to life by Satoshi—felt like we were getting there.

However, I really got interested in decentralized technology in 2016/2017 with Ethereum at first, when I jumped on the mining train that I felt I had missed out on for Bitcoin. Around that time I was at Natixis while also being an individual miner, and I made my way into the company's Blockchain Lab. There, we were assessing how the tech could be used by the industry to improve our business, and we participated in various projects. This is when I knew I really wanted to get involved professionally in the space.



Q: What does an SRE Engineer do? What are your primary responsibilities?

Great question! SRE stands for Site Reliability Engineer, but the answer is actually quite complex depending on the mission you put behind the title!

In our context, I'm responsible for making sure Alluvial's quality of service meets our business objectives. Technically, it means implementing and following indicators to help us understand if we meet the service level objectives we've set, ensuring that our software runs the best way possible while continuing to ship new features to our users, all of that within the reliability levels we are aiming for. I'm also in charge of building and evolving anything infrastructure-related to meet our current and future needs.

The other interesting part of the role for me at Alluvial is to build strong and trustworthy relationships with other engineers both at Alluvial and across the technical teams we collaborate with, as my role requires me to work closely with them.



“SRE Engineering is important whenever you want to build
something that makes your end-users happy and comfortable.
No one wants to use a service that isn't able to deliver what's expected of it, whether it's crypto related, hotel booking, or food delivery.”



Q: Why is this role important, particularly for a company supporting the development of a protocol like Liquid Collective?

Honestly, SRE Engineering is important whenever you want to build something that makes your end-users happy and comfortable. No one wants to use a service that isn't able to deliver what's expected of it, whether it's crypto related, hotel booking, or food delivery.

That being said, when we at Alluvial are developing software for a protocol like Liquid Collective we are aiming to help bring an enterprise-grade protocol into the world. That often requires more constraints than in the retail world, as the protocol's institutional participants are often themselves obliged to comply with regulations depending on their jurisdiction. For us, I'd say it's a must-have.



Q: What are some of the benefits and challenges of coordinating development systems across multiple, separate teams?

The obvious benefit for me is the faster pace you can build at. Having different teams working on their own part gives you the opportunity to work parallel streams. That is the main benefit.

Also, working with several teams can enhance your ways of working, with each individual bringing their own background and opinion that we can discuss, and, if a consensus is found, implement. I really think that we grow thanks to others, and that's an opportunity.

However, coordinating across teams comes with challenges indeed, which are often organizational challenges. It forces the Product team to be clear with what needs to be done, to plan ahead, and try to not circle all of the time. In terms of delivery, it forces you to think about alignment, dependencies, and decoupling to try to avoid some pitfalls.

The other challenge may be to manage several relationships with technology partners, and trying to align our practices amongst all of them. That's why we try to establish clear guidelines on how we want to work as a Product team.

In Alluvial's environment building for Liquid Collective, I think it's pretty straightforward to understand that the benefits overweigh the challenges of working across teams at different companies. For example, one of our goals is to integrate the protocol in different networks, each with different onchain technology. So if we manage to dedicate teams to one or two networks I think we can decorrelate streams of work—avoiding having several distinct teams working on the same network.



Q: Before Alluvial you worked as the Head of DevOps & Cloud Engineering for komgo, a distributed enterprise finance platform. How does that relate to your work coordinating across development teams for the Liquid Collective protocol, and what differences does Liquid Collective's decentralization present?

That's funny because it's quite the same, but different.

Overall I expect both situations to relate, operationally speaking. Back then I was coordinating the teams for komgo with Zied, who was responsible for the delivery at ConsenSys at that time and who I also work with now. But in our case at Alluvial, dealing with different technology partners, we might experience some overhead compared to having a single partner.

One of the key differences is the scale we are operating at. At komgo we started big with five different development teams working on different products, while at Alluvial we are starting by focusing on one network (Liquid Collective's Ethereum deployment) with one team from one Technology Partner (Kiln). Another key difference I'd say is that we are also working closely with Platforms and Node Operators, with whom we collaborate on our projects.



Q: You have operated your own miners and validators across a variety of networks. What has that experience taught you about securing decentralized networks?

Anyone can do it! However, anyone can't do it in a well optimized way.

I've been an individual miner for a few years for the Ethereum network, running 50-ish GPUs in my basement, and it's a fun activity in which you get to enter and know a community of passionate people. Personally, getting involved in it made me go back to my initial attraction for hardware, something I hadn't done for a while.

But when you start to optimize the operations, it can become overwhelming. Trying to min/max memory timings, voltage, and frequency for each piece of equipment you have is not trivial. Some of us did it the software way, but, like many others, I chose to flash the hardware to keep permanent settings. My point is, securing networks is a great activity that makes you learn new things, and helps you to get in touch with the community, but I don't think it's for everybody when it comes to maximizing profits.

That being said, if you find a great project that you want to participate in, mining or operating validators remains one of the easiest ways for non-engineers to contribute. You may not min/max as much as others with more specialization, but you will do your part. Bitcoin is out of reach for many for a long time because of the need for specialized hardware, but other PoW networks require only consumer-grade hardware, and PoS networks such as Ethereum offer solutions for people who don't fully own 32ETH to stake.



Q: France is known for having a strong crypto ecosystem. What are your favorite parts of working in web3, or of being a part of the French crypto community? ?

Yes indeed, France has a great and strong community of web3 actors—be it startups, writers, or legal firms—and that's a great thing. We have lots of builders, great incubators and some of the most recognized actors in the ecosystem worldwide.

One of the ways France can take advantage of its position and this opportunity, is to provide more legislative clarity and focus on fostering innovation in this space. All in all, this could be better—like in Switzerland, which I believe has the best web3 position in Europe—but it could also be worse!

Anyway, for me, being part of this ecosystem, especially now, feels wonderful because we get to build during the best times for crypto builders: in a bear market, when the recent events of the past 6 months reminded the community what crypto was about. And I think Liquid Collective was a great match for me, trying to achieve non-custodial staking while diversifying the participants for a better decentralization.



Q: Are there any other projects or technologies that you're excited about and would like to share?

Yes, even though I don't know if I should promote them! I mean, my roots with blockchain technology comes from the cypherpunks era. Privacy does matter to me. I've been an encryption user for a long time, and when Bitcoin came out it felt like DigiCash for the masses. It appeared that it wasn't quite close to it.

I think all Internet users should be more concerned about their privacy. So for me, when it comes to crypto, Monero (a privacy-focused cryptocurrency network) is the real deal, as a digital cash and value exchange. Its tech has been there for years and keeps evolving, the community is strong, and the usage is consistent. I consider this technology to be one of the only truly fungible crypto thanks to its privacy features.

As an encryption fan the other thing I'd like to share with you is the suite of tools created by Proton, a Swiss based company that has developed easy encryption for email, drive, calendar, and VPN. Check it out!


Thank you, Mehdi!




Interview by Melissa Nelson




Please note

Liquid staking via the Liquid Collective protocol and using LsETH involves significant risks. You should not enter into any transactions or otherwise engage with the protocol or LsETH unless you fully understand such risks and have independently determined that such transactions are is appropriate for you.

Any discussion of the risks contained herein should not be considered to be a disclosure of all risks or a complete discussion of the risks that are mentioned. The material contained herein is not and should not be construed as financial, legal, regulatory, tax, or accounting advice.

Contact