As CTPO of R3 Labs, Richard G. Brown led the technical analysis that resulted in R3 selecting Solana as its preferred public blockchain. In this piece, he explains the four critical Solana design decisions that led to his decision.
Trivia time! Which high-definition DVD standard from the late 2000s was technically superior: Blu-Ray or HD DVD?
- Did you answer “Blu-Ray”? Bzzz. Wrong.
- Maybe you said “HD DVD”? Bad luck. You’re wrong too.
The correct answer is: “Nobody cares. What matters is which one won.”
I genuinely have no idea which system was better. But I know Blu-Ray won, and I know why it won. It won because Sony included a player in the PlayStation 3. Nothing to do with its technical design.
More often than not, technical superiority simply doesn’t explain why a platform wins. This is a hard lesson to learn for most technologists. And those who fail to understand it tend to lose.
So when people ask me why R3 has committed so wholeheartedly to Solana, I always start with the non-technical reasons: the vibrant ecosystem, massive transaction volume, developer community, strong project culture, and leadership. These are the first-order determinants of success.
But something special happens when a platform with overwhelming non-technical advantages also has an overwhelming technical advantage. When these two levers work together, the results can be spectacular.
When I evaluated public blockchains as part of R3’s strategy evolution, I, of course, also paid close attention to the underlying technology. The story I haven’t told – until now – is that I discovered Solana is one of those rare special cases, where the underlying technology does indeed cash the cheques that the non-technical superiority had been writing.
Here are the ‘top four’ technical advantages of the Solana platform that led to my technical recommendation for the platform.
Solana Technical Advantage #1: Standard token implementations, not interfaces
Word association time! If I say “token standard”, what comes to mind? If you’re familiar with Ethereum, it’s probably something like ‘ERC-20’. The ERC-* standards are amazing, and they are a key part of the EVM ecosystem’s success. However, something people often overlook – because it’s so obvious, ironically – is that they are interfaces. They expose a common way to interact with contracts that implement the interface. But it means each contract has its own implementation.
That sounds perfect on one level: a common interface with diverse implementations to suit every business model. Isn’t this exactly what you’re taught to do in computer science class? But the practical implication is that every token on an ‘interface-first’ blockchain potentially runs different code behind the scenes, and that’s a problem in the adversarial threat environment of a public blockchain.
You don’t know what will actually happen when you call transfer() on an ERC-20 token contract unless you’ve examined the source code. You might think you’re sending a token to a friend’s wallet, but it could just as easily be siphoned off to an attacker.
This means that every new token deployed to most public chains has to be studied carefully. Each one has the potential to be buggy or malicious.
It turns out that Solana does things completely differently. When it comes to tokens, the Solana culture isn’t ‘interface-based’. Instead, it is ‘implementation-oriented’.
The Solana ecosystem has invested in two completely standardized and rigorously audited token smart contract implementations: a simple one for regular tokens, akin to ERC-20, and an ‘extended’ one for when permissioning, confidentiality or other advanced features are needed.
Stunningly, pretty much every token on Solana uses this infrastructure. You don’t need to worry about making a catastrophic programming error when creating your token: you just use one of the standard implementations. More importantly, this means that your users don’t need to worry that you’re going to steal all their money. And this benefit looks set to compound as DeFi becomes ever more sophisticated: more and more tokens these days need more capability than the ERC-20 standard can support, increasing the potential threat surface, whereas those on Solana can simply use the Token Extensions program. (Footnote: Token Extensions does allow the use of custom code for some limited purposes, so this is not a free lunch in all situations, but it’s a massive improvement).
This design decision is an absolute force multiplier for the ecosystem in terms of safety and productivity. But it was also the key door-opener for a phenomenon that explains a large part of the platform’s relentless ongoing performance improvements.
That phenomenon is memecoins and other high-volume token issuances. It is only because Solana has a standardized token implementation that it could become the de facto home for volume memecoin issuance and trading. Imagine if every memecoin issuance also required a formal security audit.
It’s easy to be somewhat ‘sniffy’ about this corner of the crypto market. But because Solana could capture the overwhelming majority of new issuances, it was Solana that benefited from the insanely demanding long-term stress test for the network that went along with it, as well as collecting the fees to fund the ongoing performance engineering.
In short, Solana’s unique ‘implementation-first’ token architecture enabled memecoins, which, in turn, provided the incentive and fees to drive a virtuous circle of performance engineering and innovation.
Solana Technical Advantage #2: Developer tooling
Of course, there’s more to a blockchain than tokens. The successful platforms are those with a thriving DeFi ecosystem: lending markets, liquidity pools, yield vaults, and more. And these do need custom development.
Solana’s second technology masterstroke was to pick a developer toolchain that was perfectly pitched between ‘safe’ and ‘usable’.
To see what I mean, first consider Ethereum and Solidity. Solidity’s JavaScript-like syntax was an inspired choice back in 2015: the learning curve for new developers was amazingly gentle. Ethereum’s developer adoption ran rings around that of other platforms, including R3’s own Java-based Corda. But there was a sting in the tail: it is unbelievably difficult to write ‘safe’ Solidity code. The amount of money that has been lost thanks to badly-written Solidity contracts is just mind-blowing.
At the other end of the spectrum, we have examples such as Digital Asset’s proprietary Canton platform, whose Haskell-based ‘DAML’ language has the potential to produce provably correct code, but which has a daunting learning curve, and a near-zero pool of developers as a result. Elegant, maybe even beautiful. But also a backwater.
By contrast, Solana has pitched itself almost perfectly: right in the middle of the safety and simplicity trade-off. The Rust-based default programming language, augmented with the ‘Anchor’ productivity framework, is surprisingly easy to learn, yet entire classes of bugs that are rife in the Solidity ecosystem are impossible by design on Solana.
As just one data point: I’ve been astounded at how quickly R3’s own engineers have become productive as Solana developers, from a standing start.
Solana Technical Advantage #3: Stateless smart contracts
I often mention that a key attraction of Solana was its focus on making the core mainnet extremely high-performance. Rather than depend on complex scaling solutions such as ‘Layer 2s’ and other hacks, Solana just makes the core mainnet go faster. “Increase bandwidth, reduce latency”, as the meme goes.
The attentive reader is probably asking: “OK, but if a high-performance mainnet rather than lots of L2s is the right path forward, why don’t the others just focus on this too?” The answer is that, for EVM networks in particular, they simply can’t.
This is because Solana’s designers made the important decision to make their smart contracts (‘programs’) stateless. That is: programs are distinct from the data they operate on. Instead, each instance of a contract – for example, each token issued onto the platform – has its own distinct ‘account’ on the network to store its data, such as the name of the token and how many have been issued. And each holder of each token also has their own account on the network to record their balance.
A Solana transaction explicitly declares which accounts it is reading from or writing to. For example, when Alice wants to transfer a token to Bob, the only accounts on the network that need to be written to – or read from – are Alice’s and Bob’s accounts for that token issuance. And this information is known as soon as the transaction is submitted. So if Charley is sending some of the same token to Daphne, then the validators can immediately see that these transactions don’t conflict in any way – and so they know they can process them in parallel.
In other words, this ‘stateless program’ concept means the execution of Solana transactions can, by design, be parallelised to a massive extent, and beyond anything that could be contemplated by the EVM ecosystem, even with tricks such as speculative optimistic execution.
The stateless program concept is a design we’re very familiar with at R3, as Corda does something very similar. But Solana takes it to the next level. Imagine a new high-demand coin is issued, and hundreds of thousands of people are sending tokens to just as many others. Remember, I said that each wallet has an address for each different token it holds? That means that the activity associated with this frenzy of transactions is not only disjoint from any other activity on the network, but it’s even disjoint from any other activity performed by the same people. And validators can see all of this in real-time: they can tell immediately when some portions of the ledger are ‘hotter’ than others.
This creates the opportunity for a fee market: transactions hitting ‘hot’ parts of the ledger can be priced higher than others by the validators, balancing the supply of network resources with demand, allowing ‘regular’ transactions to progress unimpeded.
This design decision above all is what enables Solana’s outrageous performance: true parallelisation of execution, and sophisticated fee-market capability to allocate block space efficiently.
Solana Technical Advantage #4: Regulation-oriented architecture
Imagine a vendor told you they had a regulatory-friendly permissioned blockchain with the following features out of the box:
- Tokens can only be issued to, held by or transacted to known entities on a real-time allowlist: 100% configurable permissioning at the token, transaction, and wallet level
- Transaction confirmation can be restricted only to known (AML, KYC) validators
- Transactions can be encrypted before confirmation to prevent front-running
- Transaction balances and holdings can also be encrypted for full transaction and wallet-level privacy
- Tokens can be frozen or seized if required
- Sophisticated ‘delegation’ rules can be added to support complex custody scenarios
You’d probably think it sounded like every other permissioned blockchain out there. But what if you were then told it was actually a public permissionless chain! And that this chain:
- Offers full compatibility with the world’s highest transaction volume DeFi ecosystem, available on demand if you choose;
- Is fully open, and has the world’s lowest fees and highest performance; and it
- Doesn’t require you to run any of your own infrastructure.
You might be a little more surprised.
Yet all the above is a description of Solana mainnet, as it exists today, thanks to tools, programs, and ecosystem services that are available to all.
It’s perhaps no exaggeration to say that Solana’s fourth technical ‘secret superpower’ is that they have secretly built the world’s most interesting ‘public permissioned’ blockchain platform hidden inside the world’s most widely used and high-volume public permissionless blockchain.
It’s an unbeatable combination: all the benefits of a permissioned chain but alongside all the upsides of a true public chain – and without the cost, complexity, and ‘walled garden’ downsides of permissioned chain ecosystems.
Conclusion
So there you have it… Solana’s architecture is very different to the EVM, and it turns out to be its secret superpower: standard token implementations, pitch-perfect programming model, stateless functions, and the world’s most advanced permissioned blockchain platform hidden inside the world’s most used permissionless chain.
This explains why the decision to align with Solana was an easy and obvious one.
Together, we’re now establishing a gateway for TradFi firms to access this vibrant ecosystem. Here at R3, we have a unique understanding of the needs of regulated institutions. With lessons learned from a decade of experience building the world’s largest collection of tokenized RWAs, technical affinity for Solana’s architecture thanks to parallels with Corda’s own design, and a deep understanding of the pain points facing today’s capital markets, we’re ready to support institutions in accessing a new world of opportunity. DeFi is ready for TradFi – and at R3, we’re enabling institutions to leverage the very best of public blockchain infrastructure with safety, ease, and control.
Acknowledgements
Thanks to Ignace Loomans and Katy Jones for feedback and valuable suggestions on previous versions of this article.
