Under Discussion: Coding Blockchains in Go

When we wanted to find out more about blockchain applications created using Golang, two people immediately sprang to mind: Tess Rinearson, who is currently working on the Tendermint Core proof-of-stake consensus algorithm, and Péter Szilágyi, a core developer on the Ethereum blockchain platform. For Behind the Code they shared what they thought the strengths and weaknesses of using Go to build these apps are, the most common mistakes made by developers working on them, and the most promising use of blockchain itself.

Please could you explain how you started coding blockchain applications in Go.

Tess Rinearson: Interestingly, in some ways it’s actually Go that brought me to blockchains! I started writing in Go to build some services and distributed systems when I was working at Medium, which was my first job right out of school. And in 2015, I looked around and I was like, “What is the most interesting place to be doing this kind of work?” And it really seemed like the blockchain space was that, even though I was very skeptical at first about the cryptocurrency aspect. So I started working in the blockchain space in 2015 at a company called Chain, which built a variety of enterprise blockchains, such as things built on Bitcoin. And since last fall, I’ve been working on a proof-of-stake consensus engine called Tendermint Core, at a company called Interchain GmbH, which is one of many companies that is in this Cosmos/Tendermint ecosystem, Cosmos being the blockchain application and network that is built on top of the consensus project.

Péter Szilágyi: To be honest, I didn’t give a damn about blockchains at first. After working toward a Ph.D. in distributed systems, doing some decentralized messaging, and trying to create self-organizing networks in Go, I was looking for a remote job at a nice company. I saw an opening at the blockchain platform Ethereum, and that’s how I joined. But it took me about two months of working on Ethereum before I worked out what the heck this thing is. I’ve been working at Ethereum for 5 years now! Compared to Bitcoin, where you just transfer value, Ethereum allows you to have small programs, called smart contracts, that actually do stuff with that value. Originally there were three clients—one in Python, one in C++, and one in Go—but now only the Go client remains, the other two kind of died off.

Why would you recommend using Go rather than another programming language to code blockchain applications?

PS: I think Go has its strengths and weaknesses. From Ethereum’s perspective, at least from all of the challenges that we’ve had, the advantages that are super-nice are that Go is really suitable for multithreaded networking applications. Because you have all these goroutines and channels, even really complex code and interactions can be simplified quite a lot. But on the other hand, one of our biggest memory issues comes from Go’s memory management—it does things really smartly but not smart or aggressively enough for us. The other weakness is number crunching. Even if Go is really fast, you can see that it is not performant enough for doing heavy cryptography, as even Go’s cryptography libraries are written in assembly.

TR: It’s also a social advantage to work in Go! People who are interested in building blockchain applications or interested in the distributed systems of networking stuff, they often like to think in Go. It’s just a common language that people use, both literally, in that they implement their systems in it, but also because it provides a framework for thinking, especially about concurrency, that people like. I’ve known a lot of people who prefer other languages, such as Rust, because Go is not the most performant language for doing heavy cryptography, but for almost everything else in the blockchain space, it’s really strong.

PS: Also, one thing that’s a huge advantage is that Go is super-simple to read. So, compared to Rust, if any new developer just looks at the code, they have a fairly good understanding.

Are you using Go to run the virtual machines that are within these blockchain systems as well?

PS: No, for Ethereum, Go is running the platform itself, but we use two other programming languages, Solidity, and Vyper, to compile down into the virtual machine. On Ethereum, there are essentially two types of accounts—plain accounts, which just store value and can send value from one to another, and smart contracts, which are actually small bytecodes. And every time you want to run a smart contract, you’re essentially just telling the very simplified stack-based virtual machine inside Ethereum, “Hey, here’s the bytecode to run this function,” and boom, you have the result. So we created those two programming languages to be able to do that. Solidity, the only viable one currently, is kind of JavaScript-ish, the goal being to make it familiar to developers, whereas Vyper syntax is closer to Python. And I know that other blockchains, such as Tezos and Cardano, use their own smart-contract language on top of their virtual machine as well.

What mistakes would you say Go developers most commonly make when creating blockchain apps?

PS: I think there are two approaches used by developers for coding blockchain applications. For example, some developers, like me, try to make every structure and every object passive, so there is no thread running beside it. If there’s some work to be done, it might spawn off threads, but the object itself is idle. The trade-off with this approach is that it can become nasty synchronization-wise, because eventually you spin up 15 goroutines and you have to synchronize between them, and since there’s no central point of scheduling that keeps them all together, synchronization can become messy. That’s why other developers usually take the other approach, where most of the objects do have an inner run loop, and then all these threads that are started on the outside communicate with this run loop via messages. But if this makes things a lot easier, it somehow also makes this inner run loop a bottleneck. This is one of the things we’re always debating within the Ethereum team!

TR: I think an easy trap to fall into is adding too much concurrency. It’s like, “Oh, let’s just utilize all of our resources as much as possible,” without necessarily thinking about the actual performance benefit you might get out of it. Like, if you’re increasing your utilization outside of bottlenecks, you’ll probably still have these bottlenecks, so you’re not actually going to be able to move anything through the system faster. The other thing, which is a bit less technical, is developers are not always consistent about the various norms of the language. I think you have to show some discipline around conforming to the Go way of doing things. And because those things aren’t necessarily enforced by the language itself, that’s something you have to learn.

PS: I agree with Tess. In Go, everything is coded to the package level, which means that if some of your developers are not disciplined enough not to touch something that they perhaps shouldn’t be touching, you will end up not being able to refactor your code. That’s something that is definitely a weakness of Go. Another pitfall that we often hit in our codebase concerns shutdown synchronization. Because of the whole networking layer of these blockchain systems, you have lots of connections and they are really unstable—you have peers coming, peers going, some of them stop responding, some of them are sending junk. So you have this random soup of unreliable connections running, usually with a few goroutines for each of those connections. And every time something disconnects, or if you just want to tear down something, you have to close the connection or wait until the connection is closed, and as you add more and more goroutines, it becomes less obvious how to properly terminate everything.

Is the Google core team taking the blockchain use cases into account when making the language evolve?

PS: I think blockchains in general have had a huge pushback from the Go community. So I don’t think Google itself really cares about blockchain use cases. But the reality is that Go Ethereum, whether they like it or not, is one of the biggest Go codebases out there. And I know that Google is using our codebase as a benchmark simply because it’s a huge codebase and it does provide a lot of information and a lot of potential places to find bugs or static analysis things.

TR: That’s pretty cool! I didn’t know that, Peter. But it’s true that there’s an uneasy relationship in general between the Go and blockchain communities, and the pushback became much stronger after the token thing in 2017. Before that, there was a bit of skepticism around Bitcoin, but the Go world thought blockchains were cool, because they’re like distributed databases or infrastructure. So there was a little curiosity from, let’s say, non-blockchain tech people. And then, after the token boom, its reputation got quite bad, I would say. And so I can’t imagine that there’s any kind of prioritization around specific blockchain features or issues in the greater Go space, but blockchain developers definitely do currently make up a reasonable chunk of the Go community.

PS: Even among the Rust community, after the whole token movement went to crap, there was this post by a Rust developer who got really angry about all blockchain and started talking really negatively about it and how he was really annoyed that the Rust community was being taken over by blockchain. And then somebody pointed out that, while that might be true, if the blockchain people go, then most of the Rust community disappears, because at this point, Rust basically is blockchain! I’m exaggerating, of course, but it’s definitely a significant piece.

What do you think are the most promising usages of blockchain?

TR: I think that the most viable use cases we’ll see are pretty boring, and they are all in the value transfer—so, digitally moving money or other assets that have some value from point A to point B. This is not a very Ethereum-oriented answer, so I apologize for that. People love to talk about a killer app for blockchains, but I really have no idea, which is partly why I work on pretty-low-level consensus protocols rather than applications.

PS: I agree with Tess, and I think the important thing to realize is that blockchains are super-slow and super-expensive! We can make them faster, we can make them cheaper, but at the end of the day it will still be super-slow and super-expensive compared to operating systems. So the only benefit of blockchains is that they are, so to say, trustless, so you can have multiple companies cooperating on something where neither of them has to trust the other, which will probably allow us to do things that mostly focus on financial interactions.

This interview has been edited for space and clarity.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Illustration by Blok

Photo: Welcome to the Jungle

Follow Welcome to the Jungle on Facebook, LinkedIn, and Instagram, and subscribe to our newsletter to get our latest articles every day!