GOLEM PROJECT (ETHEREUM) CROWDSALE DISCUSSION
The Golem Project is the new way the Internet will work.
Our aim is to use any personal computer to do jobs that are done today by servers, computing farms or supercomputers.
The ultimate Golem Net will be the truly decentralized Web, where the combined power of user's machines will deliver all the hardware resources they would ever need.
The Golem Project is a work in progress.
Golem Net is a P2P network created by the computers (nodes) running Golem App.
Any user may use Golem App to send any computing task to the network.
Any user may use Golem App to lend a machine to others.
An Ethereum based payment system is used to clear the transactions between senders and receivers.
Golem Net is a P2P network created by the computers (nodes) running Golem App.
Any user may use Golem App to send any computing task to the network.
Any user may use Golem App to lend a machine to others.
An Ethereum based payment system is used to clear the transactions between senders and receivers.
GOLEM can be used for any task that can be distributed.
use cases include the computation needed in technology, business, stock market, science and art
Internet workflow - encoding files to DCP
Stock market simulations
Big data analysis
Natural language processing
Protein folding simulation
Search for extraterrestrial intelligence
no single point of failure, no trusted authorities - even for the payment system
will be able to connect millions of workstation, thanks to a P2P architecture
all computations will take place in virtual machines and will be fully isolated from the host system
easily integrated with other solutions
the Golem standard library and support for programming languages will allow developers to integrate Golem with their applications
can be used for any type of task that can be distributed, users will have a set of tools to define and add new tasks to the network
golem’s features include a p2p network, a trading system, task definition and computation, and a reputation system.
A peer-to-peer architecture is an obvious choice for achieving decentralization and scalability. Golem will support peer discovery and communication with a specific node. Every connection will be encrypted and signed to guarantee security and authentication. Kademlia-inspired protocols will be used with a set of network techniques to go through NATs.
Trading system and payments
Golem will include a multi-agent trading system for matching users requesting computational power with its providers. It will also provide an efficient probabilistic micropayment scheme, implemented using Ethereum, for remunerating users that share their computational resources. See our nanopayments white paper for more details.
Users will define computational tasks easily using Golem's Task Definition Framework and libraries for high-level programming languages. Golem will then automatically distribute each task over the network of computing nodes.
Due to security reasons, task computation in Golem nodes will take place inside virtual machines and will be isolated from the host environment. Owners of the host machines will be able to decide how many CPU cores, and how much RAM and disk space they would like to share with other Golem users.
Golem will implement a reputation system to enforce good behavior of nodes in a decentralized environment, without relying on any supervising institution. This will allow nodes to attribute a reputation rank to their peers. A node's rank will be lowered for inappropriate behavior and increased after successful computation and will allow others to decide whether the node can be trusted.
Joining The Golem Project
Last year at DEVCON1, one of the presentations which stood out for me was Nanopayments on Ethereum, presented by Piotr Janiuk, one of Golem’s co-inventors. The idea is simple, elegant, and much amplified by the even bigger idea of Golem: a worldwide supercomputer being built on Ethereum, powered by any and every participating device on the network.
Over the last several months, I’ve spent quite a lot of time with the Golem team in Warsaw. As their software reached a proof-of-concept stage, the team, charged by a new realm of possibility, suddenly became much more serious about turning Golem into a decentralized application running on Ethereum. This isn’t an easy pursuit for a variety of reasons, and simply discussing the idea was an insightful experience.
The ethics of Golem are solid and fair. The Ethereum project will eventually see the release of Metropolis and Serenity, and with respect to the resulting EVM and Solidity changes, it would be “easy” to build, deploy, and sell a more controlled and centralized version of Golem. However, after months of deliberation, we finally reached the conclusion that now is the right time to breathe life into Golem as a decentralized service, open to all. On one hand, blockchain tech is still early, and there are many sharp edges which permissioned systems can insulate against. On the other hand however, the potential for a zero-downtime compute platform running alongside Ethereum offers orders of magnitude greater potential than a centralized software stack.
As a long-term Ethereum contributor, my passion is making peer-to-peer networking and cryptography more easily accessible to both application developers and “lay” people alike. This is the motivation behind my efforts in furthering technologies such as rlpx, webthree, and whisper (aka ÐΞVp2p). Golem is unquestionably one of the most exciting platforms that may make use of these technologies, and the team is committed to furthering their development. This will help everyone in the space to build more resilient and performant applications, full-stop. Thus, with a clear path towards better foundations of a more decentralized Internet, it is my pleasure to announce that I am joining the Golem team.
Hand-in-hand, Ethereum plus Golem are two pieces of a new movement towards a more trustworthy, and more censorship-resistant Internet. It will lead to the creation of new applications and new possibilities, which only a few years ago would have been well-nigh impossible. This is something I’m extremely excited to be a part of.
Crowdfunding — how to prepare
So, we’re almost ready for the Golem crowdfunding.
To make sure you’re as ready for it as we are, here’s a little guide on how to prepare for & participate in the GNT crowdfunding.
- The contract code will be deployed to Ethereum on 10 November
- We will announce the address of the account on social media
- Sending ether will become possible 11 November, 3 PM (GMT) – the time is based on block number which will be known when the code is deployed
- The minimum cap is 150 000 ETH — if it won’t be reached before the end of the funding, the ether sent is refundable
- The maximum cap is 820 000 ETH — contract will be closed in the moment of reaching it, even if the ending block wasn’t mined yet
- To participate you’ll need to have ETH — other cryptocurrencies are not supported
The recommended wallets to use are the Mist, Ethereum Wallet, Parity, and MyEtherWallet. We’ve just published step-by-step guides on how to use them. We recommend you read them as soon as possible.
Some of the most important bits are:
- Don’t send Ether directly from an exchange. That’s because Golem Network Tokens generated by sending ETH to the contract will be transferred to the account from which ETH came. Assuming you want to have control over your tokens, sending ETH from an exchange wouldn’t be a good idea. We intentionally made it impossible by requiring “callData” — an additional parameter you will have to include in your transaction. It makes sending ETH to our contract slightly harder (no worries, it’s explained thoroughly in the published instructions), but will assure that no one makes this mistake.
- Store your Ethereum account data securely. We know, it’s being said every time when talking about cryptocurrencies and became boring a long time ago. But please, take it seriously. Better safe than sorry!
- Check twice if the address you are about to send to is our contract’s address. It will be published on golem.network just after the deployment of the contract, 10 November
- If you are planning on using Mist, Ethereum Wallet or Parity it’s strongly advised to fully synchronize the blockchain. Note that it will take a long time, so you will have to start the synchronization several hours before, depending on your PC and internet connection.
- If you are not completely sure what you are doing, follow our manuals directly, step by step. Also, if you are quite new to the topic, we recommend you using MyEtherWallet.
The full manuals are published on crowdfunding page.
Golem crowdfunding contract deployed, start block is 2607800
We are pleased to announce that crowdfunding contract is now deployed on Ethereum mainnet. You can see it on etherscan.io.
Golem crowdfunding contract address image
- Crowdfunding start block is 2607800, approximately 11th November, 3 pm UTC
- Don’t send ETH from exchanges
- Transaction data field must be set to 0xefc81a8c
- Instructions for wallets: Mist/Ethereum Wallet/Parity and myetherwallet.
- Crowdfunding address is 0xa74476443119A942dE498590Fe1f2454d7D4aC0d but don’t send before start block 2607800
- Check out the crowdfunding page for more information and a countdown for time and block number
- To learn details on how the crowdfunding contract works please refer to this blog post.
By sending ETH to crowdfunding address, you agree to Explanatory Note & Governance Terms.
The Golem Crowdfunding — Summary
On November 11, while the rest of our nation was celebrating National Independence Day in Poland, the entire Golem team was at their computers, hard at work.
After weeks of planning, chatting with bloggers, communicating with the community, and coding, we were finally ready to launch the Golem crowdfunding event and really see if our mission resonated with the people we’re building it for.
Everyone was nervous. The question of whether or not we would even it our minimum was being discusses, beside cautious hopes that we’d hit our maximum in the first day.
This is a short recap of how we prepared, how it went down, and what we’ll be doing next.
Our main principle was simple: full transparency. Publish early, answer questions, take feedback into account.
Following that, we had three main things to prepare:
- Whitepaper and Communications
We published our draft version of the Golem whitepaper early, wroteblogpost explaining the design elements and economics of the Golem Network Token, and tried to communicate our plans, visions andideas to the community as clearly as possible. We wanted it to be clear that the whole amount of collected ETH would be used following the budget plan in the whitepaper, and that that and the GNT that was assigned to the Golem Factory would be used to finance the project until Iron Golem was live.
After listening to community feedback on the draft, we iterated the whitepaper to address thoughts & concerns, and published the release version.
2. Smart contract
Writing a token contract itself should be simple — it wasn’t.
Keeping in mind problems with The DAO, we decided to keep contract as simple as possible, having only necessary features and an additional migration mechanism that will allow us to add new features in the future.
At the community’s request, we put a timelock on developers’ tokens.
The token contract was intensively tested with unittest, and via test scenarios on Morden (testnet) and mainnet. There were also two external audits run by Jordi Baylina and Zeppelin.
3. User instruction
We wanted the process of obtaining GNT to be as easy and as safe as possible. To this end we…
- Added additional data to the contract as a safety measure to protect users from sending ETH directly from exchanges that don’t support smart contracts.
- Created two separate guides. The first one for current desktop clients (Mist / EthereWallet / Parity) and the second one for the best “light wallet” available in Ethereum — MyEtherWallet. We tested the instructions with non-technical users who didn’t have experience with Ethereum to make sure that the provided guides were easily understandable.
We’ve heard that some users may have problems with syncing desktop wallets. It’s still a time-consuming process that requires a good bandwidth, high uptime, and a lot of a disk space.
Therefore we recommended MyEtherWallet (MEW) as a preferred solution for non-experienced users. Usually it works like charm, is secure and easy to use.
We published the contract code around 18 hours before the crowdfunding block. MyEtherWallet developers added an autofill for the contract address to make the process easier for users, doubled the size of their nodes and increased the gas price to ensure the transactions get mined. The MetaMask team also contacted us to run some test with golem contract.
We had a full 3-weeks schedule of 4-hour shifts to make sure there would always be at least one team member monitoring progress, answering user questions, solving problems, etc… but everyone wanted to be there to see the countdown timer to start hit zero.
We prepared a “control room” in our conference room with a golem website displayed on a huge monitor and sit around it with laptops waiting for the starting block and listening to “The Final Countdown”. Team members from London to Thailand to Taipei were live with us.
In the first minute, the minimum cap was reached. We watched it happen & keep climbing with a mix of joy, amazement, and disbelief.
Then the problems started.
The slack and reddit post got flooded with comments about MEW ot working. Our simple, read-only, site become heavily overloaded too. We realized that the attention to our crowdfunding must be unintentially DDoSing our site and MEW’s servers. We found out later from Taylor that the main problem was in the number of json requests (200/s) which simply couldn’t be process by parity working on the MEW backend.
29 minutes into the crowdfunding, the max cap was reached. We’d succeded at the level of our most optimistic hopes.
It probably would have finished sooner if MEW hadn’t been flooded with all the requests (due to the contract construction additional transactions were required to exactly match the cap). We ran finalize functions from our control room, creating additional tokens for Golem Factory and the team and enabling users to transfer their token.“Control room”, first minutes after the crowdfunding started
…and it’s gone
We honestly did not expect that the crowdfunding would end so quickly, so we want to say sorry to all users that wanted to take part and didn’t succeeded. We should have known better, but things like that are really hard to predict.
Some people accuse MEW of not being prepared, which is unfair (and wrong). Tayvano and kvhnuk are doing amazing job for the community, delivering they great software for free, based only on donations. They also prepared themselves really carefully, and couldn’t have predicted the record number of people interested in the crowdfunding event.
It was our mis-step to point to a centralized solution as a recommended method, and we should have prepared more backup plans in our guides. Once again, we want to apologize the MEW team and all the users who didn’t manage to buy tokens during the crowdfunding.
Still — if it wasn’t for MEW, there would definitely be other issues. Maybe our site would crash (which it did, for short periods), maybe miners would stop processing transaction on time or just process only those with skyrocketed gas price.
When demand exceeds supply, there will be people who cannot get access to the thing in demand. With crowdfunding, it’s difficult to find the right spot between fairness, simplicity, and safety.
If you still want to own some GNT, you can purchase it from other users. We believe that token value should come from the value in the application and from Golem app itself, not from speculation. That’s the main reason why we haven’t decide to ask exchanges for adding tokens to their portfolio. But we never planned to hinder token transfers and we don’t mind exchanges integrating GNT.
We would like to thank all the people who took part in the crowdfunding, and express our gratitude to all of you who made it possible and supported us in our preparations with advice and motivation.
Especially we would like to thank:
- Taylor Van Orden & MEW team for doing an amazing job with their light wallet, their involvement and all-nighters before the crowdfunding and preparation of great post-crowdfunding analyses.
- Patricio Worthalter from Milliwatt & his team for being a huge and important part of our testnet from the very beginning.
- Ksenya Bellman from World Crypto Network for hosting an youtube AMA with Golem team twice.
- Jordi Baylina and Zeppelin (Manuel Aráoz and Demian Brener) for running audits.
- Aaron Davis & Metamask team for doing great job with their software and running the Metamask tests with our contract.
- The Ethereum developers for creating the platform with which all of this is possible. And the whole Ethereum community for support, great advice, and warm reception during three devcons.
- Chris Remus for great medium posts about preparation to participate in golem crowdfunding.
- Daniel Zakrisson for preparing a great crowdfunding preeliminary analysis and the final thoughtsand also Jake Lanor for critical but also insightful analysis .
- Our slack community for high quality responses and communication during pre-crowdfunding phase
We’ve been a bit quiet recently because we are really busy with preparing a detailed work plan, organizing a workflow, recruitment, and governance of the Golem Factory. We still want to keep transparency rule so we will keep you posted with our development plans and new implemented features. We would like to slightly limit the time we spend on slack, so we encourage users to use our reddit as the preferable communication channel.
We also want to welcome a new scientist in our team, laureate of “TOP500 Innovators” program at the University of California, Berkley, Grzegorz Borowik Ph. D. He’s an optimization expert, author and co-author of over 80 publications. We really hope that he’ll help use with creation of efficient algorithms for Golem.
Join our team
We’re still looking for brilliant developers ready to learn new technologies and create Golem with us. If you have experience with any of the technologies that we’re using and if you want to create golem computer with us — send us an email to [email protected]
Want to join the Golem team? Golem looking for more talented coders.
Does building the most powerful, most decentralized, supercomputer the world has ever seen sound like your kind of project? Do you want to join one of the most talked about and well supported projects in the Ethereum space? Then we want to talk to you about joining the Golem team.
Our offices are based in Zug & Warsaw, but your job will be location independent most of the time. You also don't need to speak Polish (though we'll be happy to teach you it). Check out our current open positions below.
Don't see a place for you there? You can still email your CV and pitch to[email protected]DEV OPS
# Golem project: December update ## So, it’s been about a month and a half since our 29-minute crowdfunding campaign, and we’ve been heads-down coding & planning ever since (well, after the champagne fueled celebrations). ## We’ve made a few strategic decisions & fleshed out the finer details of the 6-month plan to build Brass Golem (the P2P Blender & Lux Renderer version that will serve as Golem’s first use case and proof of concept), tentatively slated for release in May 2017. ## Golem is being built on more than one bleeding-edge technology and our highest priority is to release a robust and fully functional version of Brass Golem. Brass Golem introduces the world’s first sharing economy for spare computing power, and serves as the platform upon which we will build Golem into a worldwide decentralized supercomputer that anyone can program. All while Brass Golem itself takes the CGI rendering industry by storm, making rendering work cheaper & more powerful it’s ever been than before. ![0_1482767175749_gol.png](https://i.imgur.com/muapcrE.png) # So, what are the major updates and decisions we’ve made since Nov 11? # Throwing in some tGNT ## Up till now, the Golem Alpha has been running on our own “private” Ethereum testnet. The coin works much like ETH (besides being valueless), which isn’t ideal since the public release of Golem will run on GNT. ## Which is why we’re working towards moving all of the Alpha’s transactions over to tGNT: Test Golem Network Tokens that function exactly like GNT. With this will come the implementation of a Golem client for tGNT, moving all tests over to the Ropsten testnet, and scaling up our testnet. ## We expect Golem to run on tGNT all the way through to the Brass Golem release candidate (which we expect to run on tGNT on the Ethereum mainnet). With the full Brass Golem release will come the introduction of full fledged GNT to the network. # Golem P2P Protocols and file sharing ## Much of Golem’s robustness and efficiency will depend on having a p2p network which is agile and reliable. Today the Golem network is small, and so we can still build and test several components without running into scalability issues. But as the network grows, it will be imperative that Golem is able to scale with a diverse network. ## Golem depends on Ethereum for transactional aspects, however when it comes to p2p communications, Golem necessitates new functionality. ## One of the unsolved problems is efficient and decentralized file sharing mechanism (a kind of decentralized “dropbox”). Current alpha version uses stable, but centralized and temporary solution. We believe that IPFS (Interplanetary file systems) is one of those awesome cutting-edge technologies that Golem should be being built upon. However, we’re dealing with a problems where it sometimes stops working for reasons we don’t fully understand yet. ## To address this, we’re running a slew of additional tests to identify and solve the problem, and preparing a fallback mechanism — build into p2p protocol — that will deliver files using a different protocol if IPFS stops. # Replacing the Qt ## We will finally be replacing Qt interface with web interface as the software that Golem’s front end is running on. ## We’re changing our current interface-client communication method and preparing API specification to allow users to write their own interface-extensions for new apps with more ease. This is not critical for Brass Golem (because there will be only CGI rendering integrated by us in Brass), but it is perspective work towards more advanced versions of Golem. # Other stuff ## We’re also moving into more detailed tests & improvements of Golem’s Blender & Lux Renderer performance, refactoring Golem’s code (as well as splitting the code previously in ‘gnr’ into two directories: ‘apps’ and ‘gui’), and starting to really focus on improving UX and product design. ## By the time Brass Golem is released into the wild, it’ll be so friendly that anyone with basic computer skills will be able to get it up and running in minutes. # We’re growing & hiring ## With a clear development plan in place and secured financing, we’re recruiting! ## Three new developers have joined the team so far: Grzegorz Borowik, who’s been with us since November, Dariusz Rybi and Krzysztof Antczak. ## Before joining us, Dariusz was a lead developer for one of Poland’s bitcoin exchanges. He’s a wizard at cloud and datacenter technologies. ## Krzysztof is game developer, 3D graphics artist and Blender enthusiast. He’ll be optimizing Blender integration performance and helping with tests and UX for Blender integration. ## We need more capable developers to build this thing. Want to join? Let us know here. # Wanna be the first to get Golem updates & early access? ## If you want to be the first to know when we make a major update (like scaling up the testnet), and be invited to join potential focus groups & other in-depth chats with the team, sign up to the Golem email list at Golem.Network (scroll down to the end of the page). ## You can also download the Golem Alpha and start playing with it! ## Alright, we’re back to work. Talk to you next month — and for now Merry Christmas!
Golem and the Road to Brass
It has been a while since our last significant communication. While it could be said that we have perhaps been a little too quiet, in fact a lot has happened, with far more either imminently transpiring or being readied. With the Brass release of Golem inching ever-closer, finally we will be emerging from “heads down” mode to communicate more publicly about our progress and our plans. In this post, I would like to tell you more about both where we are, and where we are headed for the next couple of months, as we travel jubilantly along the Road to Brass Golem.
Golem’s core has made tremendous strides over the last months. Importantly, every day we come closer to an acceptably scalabe testnet. While much of it is not yet visible, we will soon switch to testnet GNT (tGNT) on Ropsten, which will allow testing transactions on Golem network in conditions as close to production environment as possible before switching to Ethereum mainnet.
Good news to Apple fans: In short order, we will also have working macOS builds to compliment those already available on Linux and Windows. We apologize for the delay on these, we have certainly heard your requests loud and clear.
Given the number of storage-oriented projects in the decentralization/peer-to-peer world, it may seem surprising that one of Golem’s remaining unsolved issues is the resource-sharing mechanism. Unfortunately, what works for storage does not necessarily work for efficient file transfer. We’ll offer a more detailed explanation of this in a separate blog post, but what is clear for us now is that this area still needs a lot of research. For example, while IPFS has truly brain-melting long-term potential, we are having some difficulty in getting it to play well with Golem’s model. Meanwhile, we are working on concurrent solutions, which is one of the reasons we have not scaled up testnet just yet: At present, we have not decided which will make it to release along with IPFS. Certainly this will be subject to heavy debate and testing, so if you are a testnet user, don’t be surprised if some data is lost in transfer over the next few weeks — you have been warned!
A growing team
In the December update, I have presented three new developers. In the last few weeks, Muhammed Tanrıkulu has also joined us as frontend developer.
But we’re not done. Two more developers will join within the next few weeks, and two more will most likely join within next few months. We’ll make formal introductions in future updates.
Given the original size of our company, these new hires reflect quite a bit of company growth. And while we are grateful for the applications that continue to flow in, for now we will slow hiring and focus on increasing the skills and knowledge of our existing newcomers. Our own experience has shown us that leaving some breathing room between hiring sprees allows us to fine-tune the teamwork, increasing efficiencies and reducing stress. We’re also still getting used to the new environment and office, which presently looks something like this:
But fear not dear readers, for the new faces aren’t only staring at challenging code; we have also significantly strengthened the team responsible for improving the user experience of Golem, which will ultimately help us in bringing it to the masses. Matt Innes and his team are thinking about how to change the rather unbearable UI we have now into something invisible where appropriate, and beautiful where it isn’t. Stay tuned.
Research & development
And what good would the Road to Brass be if we did not also report a bit on the road beyond Brass? Some insights into our future have already been provided by Alex. We’re expecting both he and Pepesza to formalize their ideas in a form of a new whitepaper, defining protocol advancements to happen in medium-term Golem releases.
Other ideas like microservices and Golem-in-the-wild (outside-of-sandbox environment) are being explored by Viggith. With so much going on recently in the space, just monitoring new concepts is a full-time job! Nevertheless, we believe that we will be able to add some value on different fronts, and will report back about that as we know more.
Finally although it isn’t entirely R&D, we are exploring licensing and remunerating for proprietary software on Golem. While this is part of what we have previously defined as the transaction framework, we do need some real life examples (real software companies) to start with. If you are developing something that you think could benefit from Golem’s decentralized compute grid, please reach out!
Growing that sweet testnet
One thing that has really kept our heads down (and frankly, kept us quiet) is the challenge scaling up our testnet. While this may not not sound too complicated, we do need at least some prospective users for more the more intensive and varied tests of the network. At the same time, we do not want to discourage our potential users by bothering them with almost certainly buggy test cycles. We need a hook, and we need bait, and we’re working on that. :)
That said, over the last couple of weeks we have solved most of the critical technical issues. Once we clear some of the resource sharing hurdles, we will switch to tGNT on Ropsten and will be ready for scaling. I do not want to give a hard date for that just yet, but this absolutely should happen soon.
The next three months
In the original roadmap, we indicated that Brass should make it out the door within 6 months of the close of the crowdfunding. As always, promising a specific date in bleeding-edge technology is risky, but we are still working towards a Q2 2017 release, and — at least for now — my judgment is that we should be able to deliver.
One closing note. During the next few months, Golem will begin to segregate its communication strategies, in order to target a few different groups (developers, requestors, providers). So if you happen to hear more about rendering on Golem, it does not mean that we have pivoted and simply want to be yet another rendering farm. Rather it means that the process of onboarding first group of users has officially started.
In closing, I want to again thank all of our supporters in the community. It is fairly unbelievable to me that we have come so far in such a short amount of time. We’re really looking forward to all that comes next.
Progress on Golem’s UX
Up to now, our communication has been hyper-focused on crowdfunding, back-end concepts, and general business development. As we’ve frequently emphasized however, evolving Golem’s user experience is also massively high in our agenda. Although it is an extension of our existing prototype targeting users of rendering software, the overall idea of the upcoming Brass Golem release is to more clearly demonstrate the viability of the overall concept behind Golem. This makes our UX-related effort even more significant.
In the graph below, we identified a number of obstacles which could negatively affect wide-scale adoption of Golem among our potential requestors, e.g. installing the application, sending the first tasks to the network in a subsidized scheme, or actually paying for the first time. We are determined to address these problems before the Brass release. Right now, we are focused on making the installation process as smooth as possible, while eliminating barriers related to acquiring both GNT and ETH, which is still a challenge for many non-crypto users. Although recent listings of GNT on Poloniex and ShapeShift definitely move us in the right direction, we are working towards efficient and attractive incentive schemes (such as initial subsidies for requestors), as well as integration with other solutions, notably services enabling the purchasing of cryptocurrencies with fiat money.
Now, to those of you who had attempted to use prior prototypes of Golem and found your eyes bleeding profusely from the sheer horror of it all, you’ll be +pleased to know that there have been some significant improvements, derived from the following assumptions:
- Brass Golem is a single, consistent application for both requestors and providers, which is particularly important for requestors willing to rent out their idle CPU cycles.
- Our objective is to align user interface with a typical workflow of our requestors.
- While some elements are specific to the rendering use case, most functionality is applicable to other use cases as well. This would be integrated by other developers once appropriate back-end solutions are developed in future releases. Of course, a developer is also free to integrate Golem more directly, altogether bypassing the Golem UI.
Here are some elements of what we have so far:
Wireframes of Golem’s UI (1) Wireframes of Golem’s UI (2)
We really have to thank Matt Innes and his team, who have made incredible progress in designing all major views available in Brass. Once we put these elements together with the latest code, we will scale up our testnet in order to assess and verify this more advanced prototype with real-world Blender users.
Exciting times ahead, everyone!
Golem for macOS now live!
We would like to announce that Golem for macOS is now available. This is still alpha version and works on a test network.
We would be grateful for your comments and remarks.
GOLEM How to Find $10M Just by Reading the Blockchain
Two weeks ago, one Golem enthusiast and GNT holder reported a strange GNT transfer transaction bug. After investigating the data attached to the transaction, I discovered that there had to be a problem in the way the exchange was preparing data for the transaction. “Oh no,” I thought, “this bug could be used to empty the whole GNT account on the exchange!” And quite a large number of tokens were stored there!
The bug was indeed the exchange’s fault, but it was also related to the way Ethereum contracts see the transaction input data and Solidity ABI (e.g. the way the methods of Solidity contracts encode and decode arguments). So of course it was not specific to GNT, but indeed to all ERC20 tokens, as well as other contracts which have transfer-like methods. Yes you read it right: this could potentially work for any Ethereum-based token listed on said exchange, if only withdrawals were managed in the same way as GNT. We do not know this to be the case, but assume it was very likely.
Ethereum Contract ABI
Raw Ethereum contracts have neither methods nor functions. Methods are features of high level languages like Solidity, and they use the Ethereum Contract ABI to specify how a contract’s bytecode is divided into methods, as well as how different types of arguments are encoded in transaction input data. (See https://github.com/ethereum/wi... for a reference.)
To invoke the
transfer(address a, uint v)method of the GNT contract to transfer 1 GNT to address
0xabcabcabcabcabcabcabcabcabcabcabcabcabcaone needs to include 3 pieces of data:
- 4 bytes, being the method id:
- 32 bytes, with the destination address (20 bytes) filled with leading zeros:
- 32 bytes, being the value to transfer, 1 * 10¹⁸ GNT:
The full transaction would therefore look like this:
Transaction input data is infinite
This is one of the messier aspects of the Ethereum Virtual Machine, but it is critical to understanding the issue fully. The EVM can read bytes of any given input data offset using
CALLDATALOADopcode. If the data in this offset is not provided in the transaction by the transaction creator, the EVM will get zeros as the answer. At the same time, the contract is able to check the real length of the provided transaction input data with the
The service preparing the data for token transfers assumed that users will input 20-byte long addresses, but the length of the addresses was not actually checked. In the aforementioned transaction, the user filled in an invalid address of a shorter length:
79735. The resulting data was malformed because the address argument took 14.5 bytes (12 bytes for leading zeros + 4.5 bytes from user input). To be precise, the transaction data was fine for the Ethereum platform as it does not care about data included in the transactions except applying fee for every byte. The only reason why the token transfer was not executed by the GNT contract was that the amount in the transaction was ridiculously high (higher than the total supply, and of course higher than the balance of the address in question). The owner of the address was really quite lucky in that the user used such a short string for the address: with some (bad) luck, the user would be able to *incidentally* empty the address of all GNT and send them to some random address. This is when we realized that bug could also be used for attack, and was very serious.
The possible attack
As you may have noticed, allowing a user to input a shorter transfer address shifts the “amount of tokens to transfer” value to the left, making the value larger. It is also very easy to find a private key to an Ethereum address with zeros in the end of the address, e.g.
Therefore, the owner of this address can enter
0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(skipping zeros) in the service interface. The attacker could then order a transfer of some value X from the service, to the inserted malformed address. This would actually cause a transfer of a value shifted by 16 bits, i.e. 65536 times larger than X, to attacker’s Ethereum account!
What we have done about it?
Once identifying the possible attack, we contacted the exchange and informed them about the bug. That was a surprisingly difficult and annoying process; our CEO Julian had a call with a support line whose representative didn’t want to listen, and continued shouting that bugs are not his business, and was refusing to redirect us further up in the chain of command. Eventually however, after couple of hours of this, Alex managed to put us through to the CEO level, and our message went through. Once we heard confirmation that bug was fixed, we reached out to other exchanges. While we had no reason to assume that they were vulnerable, we also had no reason to assume the opposite. While we have to admit that we have not tested that for other exchanges or other tokens, we were shocked and a little bit terrified to realize the potential consequences of someone taking advantage of that bug for multiple tokens on multiple exchanges: The entire Ethereum token economy and startup ecosystem might be set back by years.
What can Ethereum do about this?
While I don’t think the Ethereum developers can do much more than continuing to educate the public about how the Ethereum actually works, we might suggest additional checks added in the future versions of Solidity, for example validating that the transaction input data length matches the expected data for the given contract method.
What should exchanges absolutely do about this?
- Verify user input as strictly as possible. Simply checking the length of an address provided by a user secures them from the described attack. Moreover, validate the Ethereum address checksum if available (see EIP55), or even accept addresses exclusively with checksums. This both increases both security and user-friendliness.
- Make sure that transaction data is properly encoded.
- The generated transaction data might be also parsed back and checked against given user input.
- Check if other parameters like gas, gas price, and the destination address of the generated transaction matches the expected values.
- 4 bytes, being the method id:
Golem v0.4.0 -Testing on Yosemite and El Capitan
Golem v0.4.0 is now available
for some previous versions of Apple’s aesthetically appealing operating
systems. Please keep in mind that this is still an alpha version and
works only on our test network. We would be grateful for your comments and remarks.
fot. Grzegorz Borowik
We received extensive feedback about the macOS-Sierra version of Golem. Thanks to cool heads such as Troy Murray, Juan Manavella, Francesco Krattiger, Timothy Jones, Rolfe DH, and many others not mentioned here, we continue to eliminate major bugs and push the macOS version forward.
Why didn’t we support older macOS right away, you ask? The main issue was an incompatibility between Xcode and go-ethereum. During installation via Homebrew, go-ethereum is compiled, and Sierra’s Xcode happened to produce something that simply does not start on earlier OS revisions. Whoops.
Whether or not you will have this problem may be checked by running the compiled
gethvia the system terminal. If you receive
Killed: 9as a result, shake your fist at the gods.
The first version of Golem for macOS worked well on several machines we had for initial tests, passing them all — including regressions — because we had go-ethereum already compiled and installed. However, thanks to the full engagement of our community, the problem was appropriately detected and fixed, temporarily solved by the patched fork. In the end however, we decided to completely remove the Homebrew dependency for go-ethereum.
In short, if you downloaded Golem with an earlier macOS revision, please try reinstalling accordingly to the provided information, noting that it is crucial to first
brew unlink ...and
brew reinstall ethereum.
Golem Announcing v0.5.0 for Ubuntu and macOS
We are pleased to announce the release of Golem 0.5.0 for Ubuntu and
macOS. Your comments and remarks are invariably important to us, so we
will highly appreciate your feedback to these new versions.
Over last week we improved stability and throughput of the network as well as patched some bugs in blockchain synchronization. Please bear in mind that running Golem for the first time requires synchronizing with Ethereum blockchain, which could take several minutes.
With the growing number of testers and early adopters, we decided to systemize versioning and Golem node compatibility. Versions are identified by
major.minor.patchnumbering scheme. From now on, it is going to be possible for two Golem nodes to create a network if and only if
minorare equal, as well as if provider’s
patchis greater than or equal to requestor’s
patch. Otherwise, your Golem node should be updated. This will allow us to easily introduce patches and maintain general compatibility across the whole Golem network.
How 0.5.0/0.4.0 differs from 0.3 is going to be covered in another blog post, but the changes are very significant.
So, penguin lovers, the shell script is available here. It should work as an executable script, otherwise please run
chmod +x install.shbefore tapping
./install.shinto your system terminal.
Version 0.5.0 is also available for macOS. If you have the previous version installed, please enter
brew upgrade goleminto the OS shell terminal or install Golem according to these instructions.
Finally, a note to Windows users: you can see here that we are still at 0.3. Frankly, there is no point in using this version right now. Stay tuned, though, as updated Golem for Windows is on its way and will be available soon!
Golem Announcing the Pirx testnet and a Windows release!
Golem has made significant progress over the last weeks. Every day we are one step closer to the Brass release, fulfilling conditions that are close to the production environment. The resource-sharing mechanism, payment system, and blockchain synchronization mechanism have all made huge strides. We have also made big improvements in throughput and network stability.
This brings us to today’s big announcement: the opening of the Pirx testnet — the first Golem testnet we want to scale up to as many machines as possible. We have reached the point where we would like to encourage everyone to join. Pirx is quite different from the Golem that was released before our crowdfunding, and still different from Brass Golem, which is hopefully coming quite soon. As originally planned, we have mainly focused on rendering tasks, scalability, resource sharing, and we still provide all of these features in a “simple” (ahem) Qt frontend. The primary noticeable difference of today’s release is Golem’s ability to grow: the size of the network may now be much greater, growing to perhaps thousands of nodes, depending on demand.Photography by Grzegorz Borowik
Pirx is a separate Golem network, and although it is similar to the incoming production Golem network, Pirx and the production Golem network will not be compatible. This means that you cannot use real GNT on Pirx, and you cannot use test Golem tokens from Pirx on the future Golem network. Otherwise, they both behave in much the same way.
The goal of Pirx is to find and remove bugs, and make Golem more secure. Therefore, your involvement is essential. And while we are always open to your feedback, detailed questions on how ergonomic and useful the system is, or what would you like to add to the software, will be most useful only when our new UI is here. And it is coming soon!
We have put a lot of effort to prepare binary installers for Pirx. The installation is very simple, but varies depending on the operating system.
- Windows users: download the installer from here. When downloaded, just run
- Linux users: the shell script is located here. It should work as an executable script, otherwise, please run
chmod +x install.shbefore typing
- macOS brethren: use Homebrew by entering into a Terminal the following command
brew tap golemfactory/golem, and subsequently
brew install golem. The detailed information about the macOS release is located here.
It must be noted that a connection with the Golem network requires a public IP address. In the close future, we will provide a configuration that allows you to forward a range of ports — please be on the lookout for our blog post about this matter. At the moment however, check the configuration of your IP address, or resolve it with your Internet provider. You will find instructions here.
Recently, we received several questions about seed parameters such as:
Does anyone have a solution for the “Not connected to Golem Network. Check seed parameters."This is usually caused by node incompatibility, improper seed parameters, or a private IP address.
As you know, GNT is the main currency of the Golem network, but some small amount of ETH is needed for Golem’s smart contracts delivered by Ethereum. In Pirx, test tokens are fictional and have no value. To differentiate them, they are called tGNT and tETH (in the contract), but GNT and ETH (in the UI). For this reason, there is no point to buy or sell Pirx tokens. Although Pirx tokens have no value, they cannot be generated locally, except by tETH mining. Therefore, there is a finite supply of 1000 tGNT and 0.01 tETH provided for every node. If the supply has been spent, you will have to acquire more. The easiest way to do so is to contact the Golem team via our #golem_testers Slack channel.
There is an advantage of using another person’s computer for free, yet a disadvantage at the same time, as the tokens you earn are worth nothing. To mitigate this disadvantage, we plan incentives for testers to join Pirx — we are working on details and will announce them once we see that Pirx is stable enough. But please, for now, treat Golem Pirx as a large rendering farm and do your job for free (or for the glory)! Please look here for more information about testing — it is a simple guide for early users, where you will find some information about setup, settings, as well as creating and running a rendering task. More advanced users may check the command line interface.
Stay tuned! Every day we receive great feedback from the Golem community, and we try to respond to all the questions and issues as best we can. Moreover, we do patch and release a new version of the software as often as is required to resolve issues. Frequent patch releases will be very common during the first period of testing, but hopefully the number of releases will regularly decrease and stabilize.
We are creating Golem for you! We would be grateful for your comments and remarks. We need your help and we cannot go further without your tests! Thank you for all the suggestions. We would be grateful for sending us any bug you find, and provide feedback about stability (or lack thereof). In the case of bugs, we prefer you start an issue on our GitHub or post a message on our Slack
- Windows users: download the installer from here. When downloaded, just run
What’s new in Golem v0.5
With the recent announcement of version 0.5 for macOS, Ubuntu, and Windows, we would like to bring you up-to-date with the most significant changes in Golem.
Ethereum light client
There is no denying the fact that blockchains are the next big thing. Also, literally big — up to tens of gigabytes of data which takes hours to download. Thankfully, now we have tools at our disposal to make the synchronisation process significantly faster, keeping the blockchain data to a necessary minimum
The new and shiny version 0.5 is equipped with geth (the Ethereum client written in Go) working in a light client mode. When you type
golemappin your terminal, it boots up a geth light protocol node and waits few only minutes for initial block synchronisation. This way we assure that the required blockchain parts have been downloaded and you’re ready to roll with Golem. Considering that the application requires some data that is not present in the downloaded part of the blockchain, the light protocol will query the network and download those parts on demand.
Naturally, the light client mode is not the remedy for all synchronisation and resource problems, but in Golem’s case it comes pretty close. Personally, I am strongly for trading few more CPU cycles and a little more bandwidth to be able to jump (almost) right in, and spend those extra few hours on computation instead.
Although tGNT has been mentioned in aprevious blogpost, this is the place for a quick reminder. Golem o-point-five uses test GNT (or simply tGNT) as remuneration for providers. There are few things to remember about test tokens:
- tGNT does not hold any real value.
- tGNT is not correlated with your real GNT.
- tGNT is fun and everyone should have some.
Because of (3.), everyone in the Pirx testnet automatically gets a modest amount of test tokens from our faucet, just to start working with Golem. You will also need some test Ether, but do not worry, there is a faucet for that. Remember that test Ether does not hold any real value either.
If you dig a little into Golem’s source code, you could see that the current M.O. is payment batching. This means that your Golem node will send multiple payments at once. You can take a good look at all of your testnet transactions onetherscan.io. We encourage you to report any problems you are experiencing with payments on ourSlack channel.
macOS support is not exclusive to version 0.5, but still it has been a major step since the 0.3 pre-alpha. Running Golem on Apple’s operating system was possible due to taking these two major steps:
- Switching from Qt4 to Qt5 (the user interface).
- Implementing support for the xhyve hypervisor.
Migration to Qt5 was necessary mainly due to Homebrew’s PyQt4 installation process no longer being supported on macOS Sierra. Being more precise, building PyQt4 for Python has become troublesome. Either way, few custom PyQt4 builds and even more tests later, it was clear that Golem required some adjustments to run it’s previous GUI on OS X. It was a high time to jump to the next version of Qt and at long last introduce a macOS version.
As for the second point — xhyve is a virtual machine hypervisor built on macOS’ native Hypervisor.framework and basically a prerequisite for Docker on Mac. xhyve runs Docker’s small Linux distribution, which is in turn responsible for firing up Docker images. In short, assigning CPU cores and the amount of RAM to a Docker image implies a change to Docker VM’s parameters. Currently, that is Golem’s responsibility.
Version 0.5 has been equipped with a new resource-sharing tool, tentatively named HyperG. It’s a custom application built on top of hyperdrive, a real time distributed file system and a beating heart of Dat project. Readers who are not familiar with the Dat sharing tool may read up on it here. To be clear, the introduction of HyperG does not mean that we are leaving IPFS behind. So why the unexpected change?
During our pre-alpha tests we noticed that previous IPFS versions were opening a fair amount of TCP connections quickly. As a result, our office and home routers couldn’t keep up with connection tracking, as NAT tables were overflown and connections were being dropped. In turn, we encountered problems with resource distribution in Golem. The IPFS team has worked a great deal on this issue since then and the situation has significantly improved. However, that day we considered using other solutions. One of the most interesting was the Dat project.
Dat operates in a different manner than IPFS. There are no BitTorrent-like swarms, and P2P file transfers are point-to-point. Also, Dat does not try to persist immutable data on its network, and in fact allows the shared archives to be modified later on. Overall, it appeared to be a more lightweight solution.
We did some internal testing where both solutions were performant under different NAT configurations. Dat has proven to be less I/O intensive, and used significantly less bandwidth. We should remember that both applications operate in a different manner and serve slightly different purposes. In any case, that very same day, we began working on a prototype based on Dat that would be closer to our use case, and now it’s being tested on the Pirx testnet.
HyperG bodes well for the future, and we plan to continue the development. Unfortunately, the current version lacks port-forwarding compatibility and could use improvements in memory management. HyperG will see a new release at some point during the lifetime of the Pirx testnet, and will probably appear under a more memorable name as well.
Golem has seen optimisation in its networking code, specifically in encryption, signing and verification of network messages. This was a minor patch to the pydevp2p library, which provided a static initialisation context for libsecp256k1, instead of creating a new one each time a message needed to be processed. Testing and profiling has shown that Golem’s CPU usage dropped significantly on all supported platforms.
You might have also noticed that Golem is more performant on Windows. We have achieved this by using the Windows’ native event notification system (I/O Completion Ports) in Python’s twisted framework. Thanks to IOCP, all asynchronous code should now be more robust. This optimisation had the most significant impact on networking and communication between Golem and the UI.
Prior to the announcement of the Pirx testnet, Golem was getting back on track with versioning. This process begun with the first (since the early alpha stages) macOS version, more widely known as 0.4.0. You might have spotted few macOS nodes popping up in the vanilla test network.
Since the bump to 0.5.x, the patch version “x” has been incrementing steadily, as we fix arising issues. Unfortunately, you can’t find any change logs for these releases. As soon as the testnet version of Golem gets out of the bug-fixing stage, we plan to standardise our release process.
Last, but not the least
Finally, as Grzegorz Borowik mentioned in his last blog post, we have built Golem installers for macOS, Ubuntu and Windows. As we plan to support other major Linux distributions, we want to take it one step at a time. We would love to hear your feedback and if you find any bugs or simply feel that the installation process feels a little off, please let us know on our Slack channel.
Pre-Brass Golem 0.6.0 Released! Updated the resource sharing mechanism.
Today we are releasing Golem 0.6.0 for Ubuntu, macOS, and Windows. Though the majority of changes are not directly visible to the user, there are a few noteworthy modifications:
We’ve updated the resource sharing mechanism.
Our resource sharing application can now operate on a single port. If your computer is behind a home router (or any type of NAT), you may want to forward port 3282 (TCP and UDP) for much improved connectivity. A guide on how to forward ports on your home router can be found here.
We’ve added a “deny list” for nodes.
If a node cannot be trusted with a task that you have submitted to the network, simply put its
idin a deny list file. This will prevent that node from computing your tasks in the future. Depending on your operating system, the deny list is located at:
There is now a helpful connectivity check.
Golem detects whether ports 40102, 40103 and 3282 on your computer are reachable from the outside network. If they are not, a warning message will be displayed in Golem’s status bar.
Initial block synchronization is disabled.
The current Ethereum testnet has been difficult to sync at times. In version 0.6.0, full sync is no longer required, and will not halt Golem during startup. This is a temporary solution, as we plan to soon switch to the Proof-of-Authority testnet, Rinkeby.
We’ve resolved startup issues on macOS.
Golem’s dependencies have been updated, thus the annoying IOPlatformSerialNumber bug should be now gone.
But, it is incompatible with 0.5.x.
These new protocol changes make this release incompatible with previous versions of Golem, hence the minor version bump. Luckily, at the time of writing, our fellow Golem minions are updating the test network nodes to keep your Golem up and running.
To upgrade your current Golem installation:
In terminal, type
brew upgrade golem.
Download the installation script from here. In terminal, run
chmod +x install.sh && ./install.sh.
- Windows Download and execute the installer from here.
Thanks as always for sticking with us, and we look forward to bringing you more updates in the near future!