Special Focus on Brubeck Edition™ Part II
The Brubeck milestone is coming this year. There will be a new broker node that has the combined functionality of a Streamr client and a network node, enhanced with a plugin architecture; simple, powerful and extensible. Before the Brubeck milestone launch, we are going to run a public testnet, as previously announced. Make sure to check out Part I of this series if you haven’t already.
Brubeck testnet
We have been running testnet and broker nodes internally for some time now. And we are happy to say that everything is on track and on schedule. The testnet will be starting towards the end of August and we are confident that the final schedule for the first testnet can be confirmed soon.
In order for you to participate in the testnet, you need a host that can run the new broker node. The broker node will be available as an npm package and a docker image. So if you can run Docker, you should be able to run a node in the testnet. But if you are feeling adventurous, running the npm package in a variety of different host operating systems and environments is also appropriate and encouraged – it could be even rewarded.
We are running Node.js v14.17.0, so it might be best if you run the same major version.
There will be comprehensive instructions about how to run a testnet node in due time, but in a nutshell it is very easy:
- Wait for the announcement and instructions (via email, in the Blog and in Discord)
- Download a suitable package to run on your host
- Configure the broker node, or let it generate configuration automatically
- Start the node and keep an eye on the Discord channel about the testnets
- If you have technical issues, you can post your questions via Discord.
Brubeck testnet rewards
The goal is to incentivise the participants so that it makes sense to have a meaningful amount of nodes participating in the testnet.
Additionally, we want to reward high uptimes. In ideal situations, the broker node shows up and maintains a steady uptime.
The reward pool size depends on the number nodes participating in the testnet. If the number of nodes is small, it will make sense for the participants to promote the testnet because the more nodes there are, the bigger the rewards will be for everyone. Once all of the rewards have been triggered, the network will be big enough and adding more nodes will not increase the reward pool any further. The actual parameters will be decided closer to the launch of the first testnet, but we assume that a healthy percentage of those who have signed up for the testnet will actually show up, so it is safe to assume that the full reward size will be triggered with a four figure amount of nodes participating.
In addition to the node count, the rewards going to a given node are also dependent on the uptime of the node in question. In order to be eligible for full rewards, you need to have as high uptime as possible. A good strategy is to join early – and stay.
Brubeck testnet – how does it work?
In a nutshell, there is a special mining-plugin taking advantage of our extensible architecture that will listen on the streams to deduce if there are any reward codes to be captured and claimed.
JS client is divided into Broker and Network components. Network provides the node for connectivity. Inside Broker, we have base services, including the Streamr client. And a variety of plugins that use these base services. In the testnet, the broker node has a special implementation of a mining-plugin, which is then used to mine and claim the rewards.
Each node starts and joins the network topology and subscribes to a predefined stream. In this stream, among other things, we publish special reward codes by the Testnet Rewards Supervisor running somewhere in the network. When the testnet node – or actually the miner plugin – sees this code, it will present the code, along with some other important metrics, to the Supervisor. This way we can keep track of uptimes and see how the messages propagate in the testnet.
Brubeck testnet monitoring
In order to keep track of what is going on, you should follow the relevant channels in the Streamr Discord server. You will also be able to monitor the testnet from the console output of your own node. You can ask the Supervisor about the status of a node with a simple HTTP request, based on an Ethereum address. We will have a status app that can be used to see general overall metrics and the Network status in real-time.
Token Migration
Last time, we talked about what was left to do regarding token migration. All of that is now done; the contracts are audited and deployed. The migration tool is ready and we are aligning the schedules with cryptocurrency exchanges. The migration start date will be announced soon.
Changes
- July 2021: Latest version of network deployed
- July 2021: Brubeck Testnet and reward miner support in the JS client
- Date TBD: Drop support for unsigned data.
We will enforce the signing of the data when approaching the Brubeck milestone. Additionally, not encrypting the data is no longer an option unless the stream has public stream_subscribe permission (meaning the stream is public).
- Date TBD: OCR changes in clients and API
As part of the initiative to move the remaining parts from the centralized backend into a truly decentralized on-chain solution, there will be changes in the clients and the API. We are working hard to keep the changes in the user space as close to zero as possible – let’s see how close we can get. It is also possible that the Java client becomes obsolete if there is no longer a reason to have both Java and JS clients.
Next up
In the next Dev Update blog post, “Special Focus on Brubeck Edition™ Part III” we will iterate the testnet status.
Join the Streamr Discord server to make sure you get all future updates!
