Tackling Ethereum scalability issues

By Vojtěch Šimetka, edited by Yalor, Griff, Kris

With “tears in our eyes” we head back to testnet, as the fees on the Ethereum mainnet are just too high.

The truth is we should have been live by now, the Giveth product roadmap clearly says that we, as the Giveth Decentralized Altruistic Community (DAC), will be using the DApp ourselves in December and the first Campaigns will be created by the 15th of January.

Well, we’re not. Why? Because of CryptoKitties, because of volatility in the ether and token prices and because Ethereum is not ready for DApps to scale on mainnet.

However, we are developing an innovative testnet approach, pegging our Giveth Rinkeby token to mainnet ETH to bide us time while we build a coalition to collaborate with other teams whose DApps also need a solution.

There will likely be many updates to this system and likely more migrations in the future, but alas “Rome was not built in a day”.

Why Rinkeby? Ohh the Fees

Technically we are live on the Main Ethereum network, we just chose not to use our own DApp. We paid over 0.5 ETH in gas to deploy our smart contracts, $100 to create one Campaign, $11 for creating each Milestone. To register in our Dapp you need to pay $2.75 in gas and another $8 each time you want to donate. It didn’t take long to realize this is not the way.

Using the testnet was clearly the best option going forward in the short term, and we would use Ropsten if we didn’t have to 51% attack it to deploy our contracts. Whereas we received nothing but a warm embrace from the maintainers of the Rinkeby testnet: Péter Syilágyj created a bridge between Rinkeby and the main network just for us!

CryptoKitties now dominates that digital space as well and they are hungry for gas. Even Giveth has one!

Naming The Problem

The Giveth DApp consists of several smart contracts which require numerous transactions to deploy and operate. We have already improved the gas needed by reducing the amount of contracts that need to be deployed, thanks to RJ, our main backend developer. He rewrote the DACs and Milestones to use only one contract rather than deploying a new one each time a new DAC and Milestone are created (see the lpp-dacs commit).

However, we can not reduce the amount of transactions as there is a minimal set of actors that need to interact with the smart contracts. With the current gas price, the price to create a Campaign is about $85. To go from donation to paying out a Milestone, it could cost anything between $15 and $30 in miners fees. Just between all the Giveth Campaigns we are talking about 10–30 Milestones per week, which can cost well over $500 in gas alone. We could reduce the number of Milestones by paying them monthly, but with the prices of ether fluctuating this is not the best solution.

The big question is:

Can we reduce the transaction costs without compromising transparency, delaying payments, and wasting the donations on mining fees?

The answer is, Yes we can!

Giveth’s 3-Phase Solution

During our weekly meetings we came up with an efficient 3-phase solution that allows us to pay our contributors as soon as possible without compromising transparency. However, it does come at the cost of sacrificing some decentralization in the short term.

Phase 1: Jump Stop

In the first phase, we go back to the Rinkeby test network where the gas is free. The DApp will be used as an accounting tool to keep transparency but there will be no tokens flowing through it. The real ether will be held in the Giveth multisig and Milestone payouts will happen once a week.

All the approved Milestones on our Rinkeby DApp will result in Main Ethereum network transactions hence maintaining Giveth’s high level of transparency.

Business process diagram describing the setup with a minimal list of actions necessary for a successful payment. Any registered user can propose a Milestone, which can then be accepted by the Campaign Manager (who can also just directly create a Milestone). Once created, the Milestone Manager or Recipient can mark the Milestone as complete. The final review (approve the Milestone as completed) can be done by the Milestone Reviewer, the Campaign Reviewer or automatically through timeout. See our donation flow post and product definition for more.

However, paying directly to the beneficiaries one by one would still be expensive because every single payment requires 6 multisig confirmations. To save gas, our contributors have created a Multisend smart contract. This allows us to define how much ether should be sent to each address with one execution of the contract (and one round of multisig confirmations) paying out several Milestones in one fell swoop.

The Multisend contract allows us to send to multiple addresses with a single multisig transaction.

Status: Currently, we have our DApp already deployed to the test network and our contributors have deployed the Multisend contract on Ropsten and mainnet. Many of the historical Milestones have already been created on the Rinkeby test network version of the DApp and are starting to get paid out.

Phase 2: Pivot

In the second phase we build a deeper integration between the main and test networks. Each DAC, Campaign and Milestone will be able to directly receive donations on mainnet through special smart contract. Once the donation is confirmed on the main Ethereum network two corresponding reactions happen on the Rinkeby test network:

  1. The corresponding amount of GivETH tokens representing 1:1 the donation value in ether is minted in Rinkeby.
  2. A Pledge is generated in the DAC, Campaign or Milestone on the Rinkeby test network with the owner set to the donor address and the emitted tokens being the donation value.
Phase 2 process diagram. The green actions are newly added functionality.

From then on, it is business as usual. The GivETH tokens are stored in the Vault and Pledges move around through the DApp on the Rinkeby test network. Once a Milestone is approved as completed by the reviewer and paid out, we burn the GivETH tokens on Rinkeby and pay mainnet ether to the appropriate address. At this point, most users may not even know that they are on a test network as the DApp will behave just like it would on the mainnet.

Phase 3: Score

What more can we improve you ask? Well we don’t want to always use the test network, we only want to use the testnet for what is it intended to be used for: testing. While on Rinkeby, we may encounter unexpected behavior, unreliability, drops in quality of service or it might become completely inaccessible. We simply don’t know. Assuming the Main Ethereum network’s scalability issues are still not solved — and maybe even if they are — the next logical step (for Giveth but also friends like Swarm City) is to use a custom public POA sidechain. This sidechain would be fully bridged to the main Ethereum network, periodically verified on the main network to prove no one has tampered with it.


Every time we need to develop a new custom solution we ask ourselves: Is it secure? The short answer is yes, for the most part. Here are some selected exploits we have discussed:

  • The possibility of replay attacks: we concluded that we are protected against them as long as we use GivETH tokens. Should the network be used by other projects as well, we would need to build in replay protection.
  • In Phase 1, it is possible that a third party could manipulate the amount of ether in a Milestone by donating Rinkeby test ether to it. For that reason we have decided not to use donated values for the final accounting, but instead the Milestone’s maximal value which is defined by the Milestone Manager when creating the Milestone. This shortcoming is solved in Phase 2.
  • There is only one true danger we are aware of: It is possible that someone may send main network ether to contracts that only exist on the test network/sidechain. Although such a scenario is unlikely, because when users interact through the DApp, all the transactions are exclusively on the test network/sidechain. To further prevent such mistakes we are looking to deploy contracts that can catch any ether or tokens sent accidentally. (For this reason we would like to discourage you from making transactions outside of our UI).

Other solutions in the space

We are obviously not the only ones having scaling issues on the Ethereum Blockchain. Giveth is currently discussing potential sidechain solutions with other projects (e.g. Aragon, Swarm City, Status, Colony) and will be putting out a lot of information about what we can find.


Even though the difficulties we encountered at first seemed to be a showstopper, we believe we have created a rather elegant solution to overcome scalability issues and move the Giveth project forward.

This would not have happened without the tremendous support we have received from the Giveth team and community. I would like to especially acknowledge RJ’s work on modifying the DApp; Quazia, Alon Bukai, Oleksii Matiiasevych’s Multisend contract and finally Jordi Baylina, Adria, Peter Szilagyi and Griff Green’s investigations and development on bridging the two networks.

We would also like to take this opportunity to invite everyone to join our community: by tackling interesting problems like this one you can help us positively impact charitable giving forever!

Warm regards,