Solidity Migration & What’s Next

Six weeks ago Augur and ZeppelinSolutions disclosed an audit of the Serpent compiler, revealing a critical security vulnerability effecting the Reputation (REP) token. After a few weeks of preparation, the REP token contract was migrated to Solidity in a few hours, and we began a sprint to migrate the rest of our codebase to Solidity. The strongest recommendation from the Zeppelin security audit was to switch to Solidity and deprecate Serpent.

We’re pleased to share that in the planned six week time frame, we have completed the migration from Serpent to Solidity. There is no longer any remaining legacy Serpent code in the augur-core contracts.

We believe Solidity is a better foundation to build Augur off of in comparison to Serpent. One of our contract engineers, Micah, shared his opinion on Reddit the other day:

In my opinion, Solidity is a much more mature language. The tooling is better, it has a real type system, and its static analyzer catches a lot more than Serpent’s analyzer. It also is the language most other projects are using which means we now have a larger support network and it is easier to find answers to questions. The documentation for Solidity is also significantly better, so it requires less “poke it to figure out how it works” than Serpent.
That being said, there are a few annoyances that have bitten us, such as the Stack Too Deep issue.
Overall, I’m very happy for the migration and I believe that it will be a net positive for development velocity in the long run, as well as a net positive for security.
-@MicahZoltu

What’s Next?

Does this mean we’re ready to launch? Unfortunately, no. There are still tasks to be completed within the contracts before they’re ready for auditing.

Contracts:

  • Contracts need fee payout implemented, the REP price feed oracle built, and a number of additional pieces of information tracked for the dynamic fee system to work properly.
  • Contracts need all FIXMEs and TODOs completed / addressed.
  • Reporting escape hatch needs to be authored (a short-term emergency lever for if a major bug is found during early phases of launch).
  • Contracts need much more testing of sad paths, and more thorough testing of happy paths.
  • Contracts need to be internally audited.
  • Contracts need to be externally audited.
  • Contract deployment pipeline / scripts need to be authored.
  • Augur Node needs to be designed and written (details about this to come).

Client:

  • Finish re-skinning: portfolio, create market, and authentication views (in progress).
  • Re-skin the market and reporting views.
  • Package different distributions of Augur (downloadable client, IPFS, dApp browsers).
  • Scale and harden IPFS deployment.
  • Testing, user feedback, UX walkthroughs, improvements, etc.

The new client is about 50% complete. Our speed of development has improved since the migration. The engineering team has been growing rapidly, and we’re finding employees easier to onboard at this time in the project.

We have a rough timeline scoped out internally for everything necessary to bring us to launch. Over the coming weeks, we will share some of these broken down timelines with you, as well as updating you with our weekly development updates.

If you have any questions, please reach out to us on Twitter or Slack.

Cheers,

The Augur Team

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.