Today we are open sourcing the Radix code for what will eventually become the first version of the Radix Public Network (RPN-1) – this is by no means a finished work, but its part of our wider push to be more open with our community. 

RPN-1 is the first of three versions we will be releasing, each building on the previous, taking us from a simple, unsharded, lower throughput network, to the increasingly performant versions of RPN-2 and RPN-3, each incrementally building on the last release while preserving transactional and state history.

From our GitHub repo you will be able to follow our team’s progress, the milestones we hit, as well as any obstacles we run across along the way:

• Radix Github: https://github.com/radixdlt
• Radix DLT core consensus and networking: https://github.com/radixdlt/radixdlt-core
• Radix Engine Library: https://github.com/radixdlt/radix-engine-library

Please feel free to raise new issues on GitHub for any code-related concerns that you may have, however, the team is currently unable to commit to a particular time-frame for responding to these; when we reach the point that community coding/testing is possible we will release more documentation around our code quality criteria as well as minimum requirements for code coverage and our code security policies.

That being said, if you do want to go ahead and dive into our code and then want to ask us any questions about it, please feel free to join our developer community channel on Discord, or you can sign up to our newsletter to receive sprint updates. We’d also be curious to hear who you think has done the open-source process well – if there is any project you think we should be learning from, please post it in our Discord channel.

Why Open Source?

Radix has been working on decentralised protocols for almost 8 years. For a lot of that time, the only full-time member of the team was Dan, but Dan was not alone – first via Bitcoin Talk and later via the eMunie forums, Dan continually found encouragement, counsel and ideas from those that followed and supported his project. During these early years, he continually shared prototypes, test nets and failures. This built his first, grass-roots following.

As the crypto market heated up and we rushed headlong into the 2017 bull market, openness suddenly felt like a liability – especially for a project that was so focused on the delivery of the product rather than pitching via non-technical white papers and raising funding with an anonymous website and an Ethereum address. Having our technology taken, copied and used to raise a bogus ICO seemed not only like a real possibility, but it also seemed almost certain.

So we decided to batten down the hatches, concentrate on building our team, building a community, and building code. However, that decision now feels wrong for where the market is today; it has disconnected us from our community and it breaks from some of our closely held principles around why we got into the crypto industry in the first place.

I loosely group these ideas into three categories:

1. Transparency
2. Anti-fragility
3. Public good

Transparency

One of the core principles of building cryptographic code libraries is transparency. Many decades ago, computer security specialists realised that the best way to build resilient, secure systems was to open source the code responsible for that system’s security. It was only in the sunlight of review, use, adaption and collective research that these systems could be hardened to the point that the code could be used with confidence. Code of this type is almost entirely how we secure the internet today.

These ideas are also near the heart and nature of trustlessness. In principle, I do not need to trust your code because I can review your code – nothing is hidden, and so no surprises. In practice, the vast majority of us do have to trust as we have neither the skill/time/inclination to actually go digging around in all the software we use. However, as a system’s importance increases, the incentive both to attack and to ensure security rise together – being open source gives both an equal playing field.

It is this equal playing field that is critical – attacking a system often doesn’t require seeing the code, it is simply looking for ways to exploit how a system responds to inputs. Fixing an exploit ALWAYS requires being able to work directly with the code. Open source code is a permissionless way of letting fixes be suggested, rather than only exploits revealed.

Transparency forms the heart of public decentralised ledger technology as well. The reason we trust a trustless consensus system is that the algorithm it uses is transparent, with provable security bounds. Making the code that implements that algorithm also transparent completes the trust loop. Whether it is Bitcoin, Ethereum or Radix, the more eyes and minds that can verify both the theory and the implementation in code, the more a trustless system can be trusted.

Transparency also extends to the way that updates and patches are worked on and implemented. Open source code is not a static object, it is a living project that continues to evolve while it delivers value to the world. Being able to see what is being worked on also gives the opportunity and invitation to others to help out on things that still need work.

Anti-Fragility

The desire for decentralisation springs from a fundamental desire for antifragility. For some this is about distrust of authority, for others, it is about creating more resilience in the world’s most critical systems. If a good is publicly owned, we generally have fewer concerns about it being able to be taken away. Like any fundamentally important infrastructure, if we have to rely on it, we ideally want it to be resilient and self-repairing.

People care for the same reason they care about the internet continues to exist: it is vitally important to them. The stakes are even higher for public ledgers as this is where people’s wealth will live, not just information.

Measures for anti-fragility of a public ledger might include:

1. Once launched, can the protocol be stopped by its creator?
2. Can the protocol live independently of any single entity or person?
3. Does the protocol grow stronger as it grows in importance?

Open source is a critical component of this; if the software the network is based on is not open and free, I can never 100% trust that it won’t be taken away from me. While “open review” (e.g. the Swirlds/Hashgraph model) performs the function of “can I trust the code” it fails at the “can someone take it away from me” because it breaks the idea of collective ownership; it is no longer “our” good, it is “your” good, I am simply being given a limited right of use.

Public Good

Decentralised public networks, like Radix, are working to create a new global digital commons for the wealth of the world. This commons is designed to connect people together to create an interconnected web of addresses where the ownership of anything can be sent, stored and programmed.

Decentralisation lies at the heart of this mission – a fundamental desire to build a truly anti-fragile, self-sustaining, self-perpetuating system. One that the world can rely on and trust. That starts with Open Source.