ScalingNOW! Day 2 Summary: DApp Developers Deliberating Sensible Scaling Solutions
In our previous post we summarised the scaling solutions that are available for use today or in the near future. Developing a solution is one of two important pieces in the scaling puzzle. The second piece of the puzzle is to grasp the needs of businesses and organisations who rely upon blockchain technology and to better understand why and how they’ll utilise these platforms.
In this article we will recap our findings from the second day of the ScalingNow! Event in Barcelona.
On day 2, we sat down with a number of DApp developers to understand the scaling problems that they are currently facing. Interestingly, although perhaps unsurprisingly, teams working on disparate problems have the exact same problem areas when it comes to scaling.
The main issues facing DApp developers
DApp developers are greatly concerned with user experience. All of the developers we spoke to were worried about the responsiveness of their apps and the cost of performing on-chain operations. Users want DApps to respond as quickly as web applications: they have become accustomed to feature rich and fast responding “web 2” applications; however, such response times are tricky to achieve in the current web 3 landscape where Ethereum (for example) has 15 second blocktimes.
Despite the importance of speed, all of the developers we spoke to did not want to sacrifice cost for speed, nor speed for cost. Fast response times with an incredibly high cost wouldn’t be profitable or desireable. Conversely, long response times that are incredibly cheap just aren’t feasible from a user satisfaction perspective.
Without a scaling solution, DApp developers essentially had to pick one or the other: low-costs or low-response times. Such a situation is unworkable in the longer term if we are to see the success of a fully fledged web 3 ecosystem. Fortunately, the scaling solutions as presented in our previous article show promise of being able to dampen the impact of the cost vs speed conundrum.
Project Summaries — Decentralised Applications
- What: Aragon is a platform to run DAOs. The Aragon Network is a digital jurisdiction.
- Time to release: Version 0.5 has launched.
- Key problems: Aragon want DAOs to be deployed by people who need them (e.g people in developing countries who can’t afford transactions that cost $100). Voting must happen on chain (for governance) which hits the throughput bottleneck. To achieve these goals they need high throughput and low transaction costs.
- Favoured solutions: The team have considered a POA network with a Parity Bridge to Ethereum. They have also considered Witnet (project not presented at ScalingNOW!). A POA network may help them scale in the near term, even if that only means a 10x or 100x improvement, and provides a runway to scale further. No timeline was given for when a near-term scaling solution will be implemented.
Aragon have a desire to see cross-chain communication in order to have as big of an ecosystem as possible, and in that regard they are keenly awaiting the arrival of the Polkadot Network. If there is too much communication across the bridges, then it could decrease throughput.
An interesting alternative to help bridge the gap is the use of an optimistic UI update: update the UI before it is actually confirmed. This trick will help to give the illusion of a faster response time and improve user experience.
- What: Decenter’s team has a mission is to build decentralized applications and protocols for the Web. Their current focus is a project named Selenean, a game frameworks on the Ethereum blockchain. The vision is to build games as truly decentralized applications to enable fully serverless gameplay.
- Time to release: The team is close to launching a single player game on a testnet — this should go live in the next few weeks. Longer term, they have a plan to design a trading card game framework supporting P2P gameplay using a counterfactually instantiated state channel solution.
- Key problems: The biggest challenges are block times and transaction costs on the mainnet. Paying for each turn of the game is expensive for the player and would cause a lot of friction.
- Favoured solutions: The team’s ideal solution would be to minimise the interaction with the blockchain as well as costs involved. For a single player game they have mitigated some of the pain points by deferring update of the game: instead of forcing the player to record every move, the contract can parse a long set of moves, thus allowing the player to save the state of their game (and keep score) less frequently and at their convenience.
As for the multiplayer game framework, they are looking to build their own implementation of counterfactually instantiated state channels. This approach looks to solve both the issue of cost and hassle to the user by minimizing interaction as well as providing peer-to-peer real time gameplay not dependent on block times on the mainnet (or sidechain).
- What: Dragonereum is a crypto-collectible player vs. player game whereby users can own, trade, breed, and fight other dragons while collecting rewards and achievements along the way.
The aim is to build the “first truly decentralized digital scarcity game where developers control as little as possible”.
The community will have the ability to verify all transactions and actions without the requirement to rely on any trusted third party.
Their team will gradually pass decision making over to our users, who can use in-game currency as a token for governance.
- Time to release: < 1 month
- Key problems: Transaction gas cost and block time is too high for real time games.
- Favoured Solutions: Planning to use sidechain (poa.network or loomx.io) as a short term solution, but for a long term the team are waiting for sharding or Plasma. The believe that sidechains can resolve scalability and transaction costs problem, but questions about decentralization arise.
- What: LivePeer are providing a P2P video streaming service. LivePeer have a studio in Berlin which is publishing video 24/7.
- Time to release: Deployed on testnet, but mainnet is a couple months away.
- Key problems: The team are worried about the Ethereum block time being too long and the cost being too high. Ideally, video would go out to all viewers immediately rather than having to wait 30–40 seconds. Obviously, long waiting times provide a poor user experience.
- Currently, the team have a deployment on the Rinkeby testnet, but want to release a beta product onto the mainnet within a couple of months. The incentivising protocol was stated as being “pretty complex” which is a problem for on-chain calculation. This is why they need scaling now!
- Favoured solutions: Working closely with the TrueBit team on scaling the computation process. It solves part of the problem, but they are still learning about the other scaling solutions to increase throughput and how to make transactions cheaper.
- What: Parsec’s mission is to bring fairness and transparency to the gaming and entertainment industry. We enable on-chain scalability for game execution to open up and unite virtual worlds.
Their product is a bridge, which connects gaming to blockchain. It consists of a Plasma-enabled sidechain and an API.
- Time to release: 5 months.
- Key problems: When building Acebusters, a decentralized poker platform, the team encountered several scalability issues. Even with advanced scaling solutions like state channels they were unable to satisfy the needs of users in terms of transaction throughput and cost. The team have since pivoted to building an execution venue for transactions that is fast and cheap enough for games, but that provides the same security guarantees as the Ethereum network.
- Favoured solutions: The solution that the team are building is a Plasma side-chain extended with general computation, enabled by the Truebit verification-game.
- What: A decentralised exchange built on top of 0x protocol. Bulletin board where users come and sign intents for trade orders.
- Time to release: Live.
- Key problems: The team stated that once they hit throughput capacity on Ethereum their project will slow down, but they are looking ahead and would like to deploy a scaling solution ahead of being hit with the throughput cap. Radar Relay point out that throughput affects user experience, but there is no point overpaying for fast execution.
- Favoured solutions: Radar Relay have a keen interest in cross-chain access. The team express an interest in exploring state channels but are more interested in “parachain” type solutions (e.g. Cosmos and Polkadot).
They are currently working with the Cosmos team and they also have an in-house researcher looking at how to use the Cosmos scaling solution. The team are testing Cosmos to see if it is production ready.
Radar Relay are interested in the possibility of using the Polkadot Network in the future. The plan is to test the best-in-class solutions before they are published, such that Radar Relay is ready for day-one of the solution being launched.
We wish to extend our thanks to the @Giveth teaming for helping to co-organise this event with us (@Web3Foundation). The benefits of this workshop are immediately obvious in the feedback we received for teams and we are pleased to announce that we are already in the process of organising another event this year.
The Web3 Foundation nurtures and stewards technologies and applications in the fields of decentralized web software protocols, particularly those which utilize modern cryptographic methods to safeguard decentralization, to the benefit and for the stability of the Web3 ecosystem.
Please follow us on Medium, on Twitter, and join us in our Riot channel to discuss this article or anything else related to Web3.
Join us on Riot: https://riot.im/app/#/room/#web3foundation:matrix.org
Giveth is re-engineering charitable giving, by creating an entirely free, and open-source platform, built on the Ethereum blockchain. Our system cuts out bureaucracy and enables nonprofits to create a high level of transparency and accountability towards Givers. At any point until the moment funds are locked, a Giver can decide to withdraw them.
Please follow us on Medium, on Twitter, and join us in our Riot channel to discuss this article or anything else related to Giveth.
Join us on Riot: https://giveth.io/join/