This blog post is a reflection on what we have learned about Cardano Go development while working with Blink Labs on the Catalyst Fund 11 proposal: Open-Source Cardano Go Libraries + Docs + Andamio CLI.
At the Cardano Go Live Coding session on 2024-09-09, Chris and I talked about the evolution of the Cardano Go development ecosystem, and some current next steps. In this post, I'll include timestamps to our conversation while summarizing some the challenges we've faced and accomplishments we've made.
Apollo
Apollo is a Go library that can be used for building Cardano transactions. It is reliable for building simple transactions, but as we learned in this project, still in development.
Challenges
Ultimately, the Andamio team decided not to use Apollo in production. We built all of the Andamio Platform transactions, and in the end, there was just one (out of the nearly 20 we needed to build) that was just a bit too complicated to run reliably with Apollo, so we had to shift course. For now, we rebuilt all of the transactions with Atlas, and they all work reliably in production.
It is important to note that these are standard growing pains for any open source project in Cardano. We will continue to support the Apollo project, and the Go/Apollo version of the Andamio transaction back-end will still serve a role in Andamio development.
Update from Blink Labs
At Live Coding, Chris shared details about why Apollo isn’t yet completely reliable. Earlier this month, Cardano entered the Conway Era. With this new era come new ways of calculating transaction costs for transactions that use reference scripts. This requires updates to all Cardano libraries.
Apollo still works with most transactions. For transactions using reference scripts, updates are made but not yet pushed to the main release. While the updates work with the Maestro provider, there are still some updates needed to integrate with the Blockfrost provider.
What we learned
It is hard to update a library with many providers! Notice how the delay in the new release of Apollo is due to integrations with one API provider. Fortunately, new solutions to this problem are being built right now. Next, let's look at one such solution.
UTxO RPC
- https://utxorpc.org/
- Live Coding 2024-09-09 Timestamp
What problem does UTxO RPC solve?
In the example above, we can see that maintaining an open source library is hard when it must support many different data providers. For Apollo, this means that even after integrations are complete for one provider (Maestro) they might not be done for another (Blockfrost).
The Cardano development ecosystem would be more efficient if there existed shared standards for how different tools interact. That's what UTxO RPC seeks to provide, and that's why teams from across Cardano are collaborating to build it.
How UTxO RPC Works
UTxO RPC is an interface that defines a common language to be shared not only across Go libraries but also across programming languages. The first step in delivering UTxO RPC is to define a specification that developers can share. If you would like to learn more and view the spec, I recommend reading the documentation.
When the spec is agreed upon, teams build tools to integrate with it.
UTxO RPC is not delivered all at once, but must be implemented for each programming language. Teams build components, and piece by piece, the spec is implemented. Blink Labs is currently leading the Go implementation of UTxO RPC.
Blink Labs Starter Kits
Live Coding 2024-09-09 timestamp
By working on this project we:
- learned about Cardano Go development
- built a transaction library with Apollo
- came to understand why UTxO RPC exists
Along the way, we thought carefully about how to structure the Cardano Go Project-Based Learning course
When we did, we discovered a helpful pattern. While Blink Labs builds infrastructure and Andamio builds a user-facing application, we continuously have new ideas all the time for examples to share with new developers. At Andamio, we are building Andamio CLI, in part, as a teaching tool. The Blink Labs team is building starter kits that make tools accessible.
Together, we'll will build Cardano Go PBL by continuing to build examples, and then by writing lessons and assignments to accompany each.
Here are links to the first two Blink Labs Starter Kits:
Both can be run on Demeter, or locally. We are currently integrating these starter kits into the Go PBL course, and we will continue to build new ones, like a series of UTxO RPC and Go Node Starter Kits.
gOuroboros
Throughout this project, Blink Labs continued to make broad progress on UTxO RPC, gOuroboros, and beyond. The team is currently delivering on two other F11 proposals: gOuroboros: Cardano Ouroboros protocol server support in Golang and Cardano Node API: a Cardano Node companion written in Go .
To summarize how these all fit together: Cardano Node API implements UTxO RPC and gOuroboros supports UTxO RPC. Blink Labs has taken a broad approach to building, by covering the full UTxO RPC Spec to version 0.9, and is now putting finishing touches on Conway updates and a few bug fixes.
As always, there are growing pains. Like we saw first-hand at Live Coding, the UTxO RPC spec version must match the version on the implementation. All versions have to match the version of the spec. Teams must navigate version compatibility - all while updating different code-bases through hard fork events, and fixing new edge-cases that emerge when application developers like Andamio push Cardano to its limits.
It's a lot to take on. That's why we collaborate, and create spaces so that people can learn to contribute!
Blink Labs recently finished server-side gOuroboros interactions and has now shifted attention to server-to-client interactions, which is a requirement for building a Go Node. As Chris explained, “Now we can speak the gOuroboros protocol in both directions” -- not just asking questions, but answering questions to other clients.
UTxO RPC is the primary communication channel for the Go Node. This means that for applications using UTxO RPC, the Go Cardano Node will provide pluggable components that can be scaled when needed. Because the components are independent, app developers will be able to use exactly what they need. If that means handling more queries, can do! If that means validating transactions, great!
When this stack is fully realized, enterprise builders will have new entry points to Cardano integration, without being bogged down by block production, which is already handled by a global network of stake pool operators who will continue to run the Haskell node, which is optimized for running a resilient global blockchain.
How we’ll collaborate moving forward
Blink Labs and Andamio are here for the long-term, and we will continue working together to build tools and develop educational resources. As I described above, we have discovered some patterns to facilitate this work: Blink Labs will build tools and starter kits, while Gimbalabs will continue to write course material in Andamio.
One of our immediate goals is to continue building example applications that help developers understand all parts of the Cardano development stack, because ultimately, it's not just about learning to use Go (or any particular) libraries. Our goal is to help people build applications that solve real problems. We will make connections between courses like Go PBL, Plutus PBL, Mesh PBL and the upcoming Aiken PBL course.
As we close out this chapter of work there's still plenty to do, and we are excited to keep at it - see you out there!