Reducing friction in the adoption of private and permissioned blockchain networks through a cloud-native approach and LFDT open source projects
Back to our Developer Showcase Series to learn what developers in the real world are doing with LF Decentralized Trust (LFDT) technologies. Next up is David Reis, Lead Blockchain Engineer at BrBPO.
Currently I'm heavily involved in projects focused on private and permissioned networks, and the main focus is on making adoption easier. Because permissioned and private networks are directly shaped by business needs, there is often a lot of friction when companies try to adopt this technology. As the Blockchain Leader of the BRBPO team for DLT matters, the mission is simple but the goal is challenging: how can we easily create private and permissioned DLT networks in such a heterogeneous ecosystem? How do we orchestrate them and reduce the distance between the technical level and the business level? In my opinion, the path to easier adoption runs through automation and DevOps/SRE techniques applied at every stage of the implementation process. That is why we chose to adopt Kubernetes (Cloud Native) across all of our solutions. By using Kubernetes as our main orchestrator, we can stand up networks in any environment — from a peer running on a Raspberry Pi with K3s or MicroK8s (edge computing) to GKE, AKS, OKE, or any other cloud provider.
I have been working with DLTs since 2020, and when I first got involved with this kind of technology, I saw it as a problem solver — first for the public sector. One of our C-level executives says that blockchain is a “by design” necessity because bringing trust to the public is one of the most important requirements there is.
We also need to keep in mind that the age of paper and rubber stamps is over — at least the physical version of it. Today, almost all public services (here in Brazil) are digital, and that shift can bring its own kind of mistrust. At BRBPO, we believe that applying this technology to these services will help citizens, and the other actors involved, trust the process as a whole.
I got involved with LFDT because of open source. Open source software is democratic, and contributing to the ecosystem is essential. Sharing experiences and how we solve problems (through PRs — pull requests) is great. Even minor contributions can help people on the other side of the world. I have made a few contributions to the Hyperledger Fabric Operator open source stack. One of the most exciting moments in my developer life was getting a PR approved on Fabric Samples and receiving an LGTM (Looks Good To Me).
As a developer, getting involved with an ecosystem full of people who have very high levels of knowledge is always good. Being part of the LFDT open source community makes it possible to connect with people from many other companies, such as IBM, Walmart, and Consensys. You really see people from all around the world helping each other. Beyond the technical exchange, being close to this community keeps me connected to the bigger reason I got into DLT in the first place: building the kind of trustworthy infrastructure that public institutions and citizens can actually rely on.
I have no words to describe the experience of having a contribution approved and merged in an ecosystem with so many specialists. It is a very gratifying experience.
Contributing means sharing expertise. Often a problem we are facing on our side is also happening in many other places. Contributing to the community, getting in touch, and sharing experiences can help a lot of other people. There's also a bigger picture: when we improve open source DLT tooling together, we lower the barrier for the public sector to adopt trustworthy systems. A fix we contribute today can end up strengthening a public service that thousands of citizens depend on.
Agentic AI in the development process. The hardest part of this kind of work is automation, and AI now makes it possible to automate very large and complex pipelines for deploying heterogeneous networks across many environments — mainly automating the implementation process behind environment provisioning. With AI's help, creating networks on any cloud, as well as bare-metal deployments, on-premise, and edge computing, is now achievable at a lower development cost. What excites me most is what this unlocks: if standing up a trustworthy, auditable network becomes cheap and repeatable, then bringing that transparency to public services stops being a big project and becomes something almost any institution can afford.
LFDT has a lot of channels. I first got involved through the LFDT email lists , GitHub (the Fabric Samples and LFDT Labs repositories), and Discord.
What is the best piece of developer advice you’ve ever received?
Apply the KISS methodology: Keep It Simple, Stupid. The only certainty is that we will make a mistake at some point (and not only during the software development process). Simple things are always easier to fix. I usually raise a flag whenever something I am working on starts to get too big or too complex. (Nowadays that also means spending too many tokens.)
Code assistants and Kubernetes. Claude AI, Codex, Antigravity, and others are making it easier to implement complex pipelines, especially for heterogeneous environments. The challenge is maintaining the KISS approach with AI coding. We need to be very careful and pay close attention when creating the SKILLs and SPECs, so that the agents produce clean and easily readable code.
Blockchain and Kubernetes were made for each other.