Everything you need to know about the Trinity Ethereum client
Trinity is a new client for the Ethereum blockchain, akin to the more mature geth and parity.
The client is primarily developed and maintained by the Ethereum Foundation python team, Guilherme Salgado from Consensys, and around 40 other contributors from the broader Python Ethereum community. It has been under development since November 2016 , recently hitting a major milestone with our first public releases during the last 2 months. You can check out our latest release here.
While Trinity is currently considered alpha level software it can already do quite a lot.
- Fast-sync with the Ethereum Mainnet and Ropsten.
- Run in light client mode.
- Serves some of the
eth_JSON-RPC endpoints. - Launch a python REPL with a connected web3.py instance.
This is only the beginning as there are big things planned for Trinity’s future.
Trinity will be a full Ethereum client with a comparable feature set to geth or parity. Building such a client in Python isn’t trivial. Python in not known as a fast language, nor is it very good at concurrency, both of which have posed some challenges. But despite these difficulties, Python has some very nice properties which we think are important.
- A large and growing developer ecosystem.
- Low barrier to entry.
- Expressive and easy to read
The Trinity and underlying EVM implementation called Py-EVM are written to be easy to read and understand. Reading the code from these projects is probably the easiest ways to get a deep understanding of the Ethereum Virtual Machine.
An easy to read and understand codebase has made onboarding new developers to the project easier, major refactors go smoother, and debugging faster. And because of the dynamic nature of Python it has been easy to experiment with and explore the protocol, not to mention easier debugging when things go sideways.
Supporting the ongoing protocol development is another major use case for Trinity and Py-EVM. Many of the core protocol development teams use Python and much of what is being built is done using Py-EVM and Trinity.
It is easy to forget that the Ethereum network is still in the early stages. We still have two major phases ahead of us as we transition to Proof of Stake and see what scaling a blockchain via sharding looks like. Supporting this work is a key mission for the Trinity team. We build and maintain the tools so that they can focus on moving the protocol forward.
Trinity also aims to be a software platform. We’ve started work on what we’re currently referring to as our Plugin API. Plugins will be software that runs alongside Trinity and which is managed by the Trinity process. A plugin could be something as simple as the code which reports information to ETHStats, or something as complex as implementing Swarm. Anyone who runs a Trinity node should be able to install a plugin as easy as installing a normal python package.
We’re already using experimental plugin APIs to build our transaction pool. The Trinity Python REPL is also written as a plugin, and most of our new features are now being built on this API. By dogfooding these APIs we can be sure that they support the broad use cases we’re targeting as well as ensuring that they work as expected.
One of the more compelling use cases for plugins that we’ve thought up are application specific plugins for the popular Ethereum protocols. Using MakerDAO as an example, the plugin would likely expose some new JSON-RPC APIs which expose specific data like the total supply of DAI. In the case of something like Augur the plugin could run a webserver to the Augur web application.
Protocols like TrueBit requires external software to execute the off chain computations as well as check the results of other computations for correctness. We think distributing these types of software as plugins will lower the barrier to entry for wider participation in these protocols. It may also be easier to write them as plugins since Trinity will manage starting and stopping the application as well as providing it with a reliable connection to the network.
There are many more compelling use cases for plugins which will have to be explored in another blog post.
If you want to try out Trinity, you can do so today. Our quickstart guide should have everything you need to install and run the client. In the coming months we expect to get into a regular cadence with our releases.
Development is currently focused heavily on syncing, both making it more robust, as well as improving performance. You can expect syncing the Trinity client to take 3–5 days to sync the chain data and another 4–5 days to sync the chain state. We expect these numbers to come down significantly in the coming months.
Alongside this work we’ll be incrementally filling out other functionality like running as a light server, transaction pool management, and fleshing out the remainder of the JSON-RPC API.
I’m notoriously bad at predicting the future, but I expect we’ll see a release of Trinity within the next 3–6 months which can sync with the network in only a few days and which is reliable enough for non-production use cases.
Stay tuned. We’ve only just begun.
