It’s been two weeks since we released Brass Golem Alpha2 0.8.1 and here’s a summary of the features and bug fixes we were working on during that time.
What is a payment matching?
Payment matching-related code has been in our codebase for a long time. However, it hasn’t been production ready. We’ve been working away on fixing those issues and you will be able to see the result of that work in the next Golem releases. Golem depends heavily on the Ethereum network. Its main use is to carry out payments. Unfortunately, Ethereum’s payment fees make it unsuitable for the levels of micropayments we in Golem aim for.
Here’s where a payment matching — paying for a couple of requests collectively — becomes useful. Of course this needs to be supported by the application — the app needs to be instructed that when a payment doesn’t arrive immediately, it doesn’t mean the requestor is cheating. It needs to a posteriori match multiple payments that arrive later on — hence the name payment matching. So what stopped us from including the payment batching code in our previous Golem releases? — We found some issues on the database side. There was also an issue with encoding of the Ethereum addresses which hasn’t be done in the same way consequently — said Grzegorz Gruszczyński, our software engineer. In fact, these are the sort of bugs which pester the programmers most.
Changes related to the client behaviour
As you may have noticed, while requesting a task, you have to specify the maximum price for a task. This could create a potential chance for dishonest providers to cheat — they could always specify the maximum allowed price and claim they have utilized all the time they had.
While this mechanism will be redesigned after Brass, we decided to make all clients equal for the time being. The final version will always claim the maximum price and time limits. In the future the maximum price will not be known for the providers and bidding will take place instead. Still, this requires major changes to the protocol.
BitTorrent over devp2p
While BitTorrent is mostly associated with file sharing services, its uses are much broader. Many Linux distributions use BitTorrent for sharing images, even music artists have been known to choose these means of distribution, when they want to publish songs free of charge.
Basically, BitTorrent is a protocol for exchanging files in a P2P network with a simple goal: allow the uploader to leave the network as soon as possible. Golem requestors also need to transfer files e.g. send their rendering sources to the providers. We currently use our customized solution based on Dat project, called HyperG. You may have noticed it if you decided to install from source. So what’s the downsides of using HyperG? While HyperG works in the most common scenarios, we came across some corner-cases, where it fails. For example, HyperG uses a separate connection for file transfer. This means that, if the network resources are heavily limited, the nodes can have a working connection for Golem, but another, new connection cannot be established.
Our software developer Wojciech Dubiel implemented a proof-of-concept implementation of the BitTorrent protocol on devp2p. It’s not precisely BitTorrent — we had to modify and tailor the original protocol to fit with Golem.
At the end of September we conducted several tests to see how the PoC behaves. We tested three different scenarios:
- all nodes are in the same local network (at the office),
- the nodes are in different Amazon AWS locations,
- the Golem nodes are our employees’ personal, home computers.
The third one was the most important since it resembles the network quality of the average node. While LAN is fairly fast and Amazon AWS nodes are very well connected, the home Internet access of our developers is no different than average. The results are impressive and we certainly want to replace HyperG with the BitTorrent over devp2p approach in the future. It’s one of the improvements that may be added to Golem in the future.
GUI onboarding improvements
What landed in the repository in this case are fixes of a couple small glitches, which often cause misunderstandings amongst our users. Big thanks to Vincent Olislagers for giving us feedback about some of them.
For example, people have often missed the text field for inputting the node name, being surprised later on that their computer is an anonymous node. Besides, some of you didn’t expect an onboarding screen and were confused what to do. Some people expected keyboard navigation and it didn’t work either.
Our frontend developer, Muhammed Tanrıkulu, addressed this issue. What he did was rewording many of the informative texts during the onboarding stage. Additionally, the GUI received support for handling input confirmation with the enter key and the node name field now has focus when it’s displayed to the user.
Another improvement was adding a spotlight to the tutorial screen. What’s that, you may ask. Simply, when some of the interface elements are described during the onboarding, the irrelevant part of the UI is dimmed, so that you can easily find out what the tutorial refers to.
Moreover, we slightly modified the way the balance animations work. Previously the counter was exposed to a gradual change from zero to the actual balance whenever the dashboard was visited. This was confusing to some users. Now the balance animation only happens when something changes — and during startup.