Table of Contents
Special Focus on Brubeck Edition™ Part I
Since the latest update, there’s been a lot going on when it comes to Streamr project developments. Roughly speaking, there are circa 200 completed separate issues logged into our issue management system since the last dev update. These are now more Brubeck focused so perhaps it’s time to look at the big picture.
As can be seen from our roadmap, the Brubeck milestone is coming by the end of 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 that allows us (or eventually anyone really) to extend the broker node to include whatever functionality one might need. Simple, powerful and extensible.
So when can I run a Node?
As many of you have seen, there was an announcement about a public testnet coming soon. Big thanks to everyone for registering to join the effort!
The first opportunity to run a node is when the testnet is public. We’re already running the first Brubeck testnets internally to make sure that everything goes smoothly once we’re ready for the public testnets. Currently, we estimate that the first public testnet could start at the end of August, but we will not take that step unless we are ready so the date might change.
So what do I need to run a node?
Not that much. Current understanding is that we could publish what is needed to run the testnet as npm -package and a docker -container. So you can choose one or the other depending which suits your own setup better. The operations are not too complicated; there is not that much CPU needed in order to be able to mine the rewards in the testnet. We can talk about the rewards mechanism a little bit more in future blogs, but there should be no need to invest in new hardware — most likely whatever desktop or laptop you have now will do nicely. While running the node there will be some observable CPU usage and network traffic, but you should be able to do whatever you were doing with your laptop without noticing much of a change, even if you are participating in the Brubeck testnet by running the broker node at the same time.
Do I need $DATA to run a Brubeck testnet node?
No, but you can get $DATA as a reward for participating in the testnet. There will not be staking in the testnet, in the sense that the testnet participant should cover this. How much you will get is based on your participation in the testnet, uptime and the ability to propagate and receive messages in the testnet. The more participants we have, the better the rewards. But bigger hardware / network bandwidth does not mean you get more rewards — we are running the testnet to see it in action in an environment where the broker nodes are running under very different conditions, as we believe that will happen in real life. The broker node run in the testnet knows what streams to join and has an automatic mechanism to claim the rewards, or ‘mine the bounty’, if you prefer to think of it that way. All you need to do is configure your wallet address, launch the broker node and enjoy the feeling of being a True Pioneer (and there are the rewards too).
About Token Migration
Previously, we were considering extending the ERC-20 standard with ERC-777 standard, but we did not go there due to higher gas costs and the fact that ERC-777 is not that used yet. So, the new token will instead implement the more minimalistic ERC-677 standard, which enables token recipients to react to incoming tokens, and has the potential to improve the UX with many smart contracts and cross-chain bridges.
The new contract will also support the “permit” function as defined in EIP-2612, which allows for a third party to pay gas for transactions — another important UX enabler. The new token smart contract implementation is ready and waiting to be audited. The migration contract is ready and waiting to be audited. The migration page is almost ready; dev work is in progress but we are almost there.
As discussed in a previous post, the Canvas and Dashboard features are no longer supported and have been removed. At the same time when we archived the repositories for those, we took the opportunity to give the repositories new, more meaningful names.
- engine-and-editor -> core-api
- streamr-platform -> core-frontend
The old names should still work because github takes care of forwarding the requests coming with the old repository name to the new repository, but it would make sense to make a note of this change to be sure to be pointing to the correct repository.
For some time now we have been entertaining the idea of using a more ‘monolith’ repository approach when it comes to the network-related deliverables. Previously everything has been in its own repository, making the tracking of dependencies a little bit more difficult than it should be and slightly obscuring the impact that changes may have across repositories. So we address all of this by moving into network-monorepo. In future, this will hold all the wisdom of the repositories listed below:
- network (streamr-network)
- broker (streamr-broker)
- client (streamr-client)
- protocol (streamr-client-protocol)
- test-utils (streamr-test-utils)
- cli-tools (@streamr/cli-tools)
- cross-client-testing (com.streamr.client_testing)
We are already archiving some of the repositories mentioned above, and will move the rest as soon as it is convenient. Something to keep an eye on.
As explained before, we want to enforce the signing of the data when coming towards 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).
In the blog post, “Special Focus on Brubeck Edition™ Part II” we will focus again on the testnet and what more we know about the activities and schedule by then. Also it is a good opportunity to dive deeper into the details about on-chain registry and explain how we ascend into further heights of true decentralization.
See our Discord and subscribe to this blog to make sure you get all future updates!