Developer Tech News #5
There was a lot of traveling for Golem around Europe last week and we will describe that in the further part of this post but it didn’t discourage us from the most important task at hand — technical development.
Securing against DoS attacks
When Golem was still in its Proof-of-Concept phase, protecting the network against DoS attacks was of secondary importance. Now, as we approach a mainnet launch, security issues have become paramount. While there’s no complete solution to all possible hypothetical security issues, as of this week we have certainly made significant progress.
An example of a basic attack on the Golem network would be to flood the network with numerous computation requests. This would deprive the rest of the network of computational power and crowd out other user requests. The change that is just about to land will combat just such a hypothetical attack.
When any requestor wants a task to be calculated, he or she broadcasts a task request to the network. The easiest countermeasure we can employ here is just to limit the number of tasks from the same requestor which are stored by a single node. This should limit the number of requests that can be propagated into the network by a single requestor.
This solution could still be circumvented if a malign user employed something more sophisticated like a Sybil attack. In this example a malign user could spawn numerous, malicious nodes with the aim of outnumbering the non-malign ones. Figuring how to disable this next level of attack is part of Golem’s ongoing research and development. Except to hear more in the coming months.
Task protocol on devp2p
As you might know from our previous updates, we’re in the process of swapping our network stack. More precisely, we will stop using our homebrew networking solution and start using the Ethereum devp2p stack.
The next part of the job is to move the Task Protocol to devp2p. It’s used for “anything tasks” — requests, assignment, status reports, result exchange. As Marek Franciszkiewicz, one of our Senior Software Engineers, explains:
Moving our task protocol to devp2p is a great simplification of what we use in Golem. We got rid of 3/4 of the used messages and a separate server running in the background
Right now we have a working prototype. What comes next? We want to create virtual machines on Amazon AWS running the new Golem nodes and continuously testing the whole project. We will keep you posted on that too and other features that should get us closer to Brass.
Traveling with Golem’s friends
In many ways that was the main purpose for our recent travels. In our last Tech News posting, we told you that Monday began with our annual company getaway where we were working hard on the strategy for Brass’s release and beyond. For many of us, it was only the start of traveling. On Wednesday Golem was in Amsterdam at “Bitcoin Wednesday”, the longest-running monthly Bitcoin & Blockchain conference in the Netherlands. Then on Thursday a number of us from the Golem team travelled to Berlin to officially announce our cooperation with projects like Streamr and Qubes OS and discuss our future relations with OmiseGO and Plasma, which we perceive as technologies complementary to Golem. In fact, Imapp — the company where the concept of Golem was born is already involved in cooperation with OmiseGO. — We need to build the technological stack for Web 3.0 — said Piotr Viggith Janiuk, Golem’s CTO and Co-Founder, explaining the idea of our meetup’s title “Golem and Friends”. — This stack needs to be reliable (and that’s what Streamr brings). It needs to be safe and secure (and Joanna Rutkowska’s Qubes OS is going to provide that) and at the same time it has to be very, very efficient. As we know Ethereum evolves but still it has slight problems with scaling and that’s where Plasma helps. And as for us — we are there to provide computations and resource sharing. The other parts? That needs to be done by our friends — he added. You can find a link to more here.
—
Marcin Mielniczuk contributed to this article
