2019 was a great year for Quantstamp. We released a book on smart contract security, helped push forward the DeFi movement through some key audits, launched our Bounty Protocol, expanded our presence into new markets, and more.

Publishing Fundamentals of Smart Contract Security

It was a lot of work, but we were very proud to release Fundamentals of Smart Contract Security earlier this year. We’re so thankful for the Quantstamp community, investors, advisors, professors and friends who’ve supported our mission and made this possible.

As the seminal book on smart contract security, we were grateful to be able to share our team’s knowledge through this book and move closer to our vision: helping the first billion people use blockchain securely. If you haven’t already, be sure to purchase your copy on Amazon.

Notable Audits

Nuo Network

In April, Quantstamp audited Nuo Network, a debt marketplace that connects lenders and borrowers from around the world using smart contracts. This was one of our first DeFi audits, one of many to come.

Backed by ConsenSys Ventures, Nuo Network revolutionized decentralized lending by using lending pools. This approach makes things much easier for both borrowers and lenders, who no longer need to match loans with each other.

PoolTogether

Later in the year, we audited PoolTogether, a Decentralized Finance (DeFi) project which leverages blockchain technology to facilitate better outcomes for people. PoolTogether is a no-loss-lottery. If you do not win the weekly lottery, you still keep the money you spent on the ticket.

The way this works is that the money spent on lotto tickets enters a pool that is lent out on Compound. When a winner is selected, the winner only receives the interest generated from Compound. If you lost this week’s lottery, your funds are automatically entered into next week’s lottery. Users can withdraw their funds at any time.

The no-loss-lottery is only PoolTogether’s first product. They are considering creating a product that would allow wealthy individuals to donate interest generated off of their wealth to charity.

rDAI

More recently, we’ve been securing next generation of decentralized finance applications by our work to help secure rDAI. rDAI is a DAI-like token that lets users keep a stable balance while directing the interest on that balance wherever they want. That interest can be used to support charities or nonprofit organizations, pay friends, or even invested in promising new DeFi projects.

Sablier

This past month, we secured Sablier. We are moving towards a future where employees are streamed payments the moment they generate value for their employers. Sablier is pushing DeFi forward by allowing employees to receive a “continuous” salary.

In most jobs, employees front-load their labor, and their employers are indebted to their employees until the next pay period. Most companies settle their debts with their employees every 1 to 2 weeks; however, there are situations where employees urgently need to pay for something like rent or food, but they must wait until payday to receive money owed to them.

Sablier allows employers to make a one-off deposit and pay their workers on a continuous basis. Employers can allow their employees to withdraw money owed to them on a per-minute basis or even shorter.

Sablier suggests that continuous payments are ideal for freelancing, subscriptions, taxes, consultancy, rent and car parking. We are excited to see what Sablier can achieve in 2020.

Moving DeFi Forward

Sablier, rDai, Nuo and PoolTogether are part of Decentralized Finance, a movement to replace traditional financial products and services such as checking and savings accounts with decentralized applications built on blockchain platforms such as Ethereum. Top DeFi Projects like these are choosing Quantstamp to make sure users funds are safe in the DeFi applications they create.

DeFi is this year’s killer app for blockchain technology. The total value of digital assets locked in DeFi is currently over $600 million US dollars and has doubled since the beginning of 2019 despite the bear market. DeFi is changing the way we think about payments, savings, generating passive income and more; however, it will fail to realize its full potential unless users feel confident that their assets are safe while using DeFi.

Security is a legitimate concern. In 2017, over a quarter billion dollars worth of digital assets were lost or stolen due to bugs in blockchain applications. Quantstamp will continue securing the future of finance by working with leading DeFi applications in 2020.

Ethereum Improvements

As we move into 2020, Ethereum has just undergone the Istanbul upgrade. This update enables near-term scalability improvements while we wait for ETH 2.0 As Circle CEO Jeremy Allaire explains:

“With the Ethereum Istanbul hard fork, zero-knowledge Rollups are now possible and will allow Layer 2 scaling on Ethereum supporting upwards of 3000tps (larger than Visa) while maintaining decentralization and privacy. This is a big win for ETH-based stablecoins, [like USD Coin (USDC)].”

We are also excited about cross-chain developments happening on Ethereum and other platforms.

In April we audited Kava Token. Kava is a cross-chain CDP platform built on Cosmos. Similar to how MakerDAO allows users to collateralize ETH to create DAI, Kava allows users to collateralize other assets including BTC, ATOM and BNB into CDPs to create stablecoin balances.

Besides Kava, more platforms for other assets are emerging such as RSK and Echo. These platforms allow Bitcoin — the largest crypto-asset by volume and liquidity — to be used for DeFi. While DeFi has experienced explosive growth in 2019, we think it’s just getting started.

Latest Release of the Quantstamp Decentralized Security Network

In June, we released the latest version of the Quantstamp Decentralized Security Network. With open source code available on Github, this version of the protocol allows anyone to run a node and help secure smart contracts on a decentralized security network.

The Quantstamp Security Network V2 allows users to run decentralized scans on smart contracts for potential vulnerabilities and store a decentralized report of the results directly on the Ethereum blockchain.

This latest update features an enhanced user interface and features a decentralized design. Anyone interested in running a node just needs to follow these instructions.

The Quantstamp Decentralized Security Network was also profiled when Quantstamp won the Blockchain in Cybersecurity Use Case Awards this fall.

Bounty Protocol

Another whitepaper goal for Quantstamp was a decentralized bounty protocol. We delivered on this promise with an open source bounty protocol anyone can build on. It uses cryptoeconomic incentives to create a decentralized marketplace where bug bounty hunters can get paid to find vulnerabilities in smart contracts that automation cannot detect. It uses the power of smart contracts and cryptocurrency to leverage software engineering talent from around the world to add an essential layer of infrastructure for blockchain security.

Expanding our Presence in New Markets: Dubai & Japan

With Japan being an important market in digital payments, we were excited to expand our presence there in 2019. As blockchain technology is adopted in the financial world, smart contracts will play an increasingly important role. The market for smart contract-driven applications in Japan is strong and has the potential for even more growth in the future. Following investment from Nomura Holdings and Digital Garage, Quantstamp established a limited liability company, Quantstamp Japan GK, to assist Japanese startups and enterprises in using blockchain technology securely.

Dubai is aiming to cement its reputation as a global leader in technology innovation and the smart economy. With this in mind, we were honored to win first place at the Smart Dubai Global Blockchain Challenge. Organized by Smart Dubai and Dubai Future Accelerators, the Smart Dubai Global Blockchain Challenge is part of the government’s Blockchain Strategy 2020, where blockchain will be used to enhance the quality of life of its citizens. We delivered on this goal by working with the RTA on blockchain technology prototypes, and are currently working with other companies in the region to leverage blockchain to improve the lives of citizens in Dubai.

Doing Our Part to Change the World

Earlier this year, we were proud to be involved in a joint effort among multiple agencies–including the World Economic Forum–to explore the potential of blockchain to reduce corruption in corporate procurement in Colombia. It’s estimated that 20–25% of funds are lost to corruption globally at the government level, so this is a really exciting application of this technology.

Another great initiative Quantstamp participated in was an alliance to unveil the first social impact stablecoin on Binance. The Binance Charity Foundation’s Pink Token Care Project was launched with the aim to increase opportunities for women in underdeveloped countries by providing them with feminine care products. With the stablecoin being tied to a years’ worth of these products, the Pink Care Token Project provided a tangible example of using blockchain technology to create concrete improvements in society.

Looking Forward

We had the opportunity to work on exciting and meaningful projects throughout 2019 and are incredibly thankful to the Quantstamp community and their continued support. We look forward to what 2020 holds and hope you’ll continue to follow our journey as we tackle new and exciting milestones in the coming year.

2019 Year in Review was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quantstamp/Quantstamp Japan co-hosted and participated in a hackathon “Decrypt Tokyo 2019” from June 8–9th. It was designed for blockchain beginners and intermediates. Over 100 hackers & 20 teams participated in the event. Sponsors including Microsoft, Curvegrid, Metaps, and more helped to make this event a huge success. Participants included students from Japan’s top universities such as Tokyo U as well as mentors from top crypto projects such as Kyber Network and OmiseGO.

We were honored to help organize such a great event for the Japanese blockchain community. Our intern Chang Yu and Security Auditor Poming Lee also participated in the hackathon directly, creating a trust-less password manager. Check out “Encrypt my Data”

Decrypt Tokyo was organized by Quantstamp as well as Neutrino and HashHub, which operates blockchain co-working space, and NodeTokyo, the first tech-focused, international blockchain conference in Japan.

We’d like to thank Mayato Hattori from Neutrino, Yoriko Beal from Hashhub, Yusuke Obinata; a.k.a Obi from NodeTokyo for your contribution!

The Japanese Blockchain Community

“A lot of people have started leaving from the Blockchain industry in Japan…”

This trend led us to holding the hackathon in the first place — as it’s an opportunity to introduce hackers from other industries into blockchain. At first glance, you may think Japan has a strong blockchain community since we have lots of communities, seminars, and meetups. This is true to some extent and there are many active members in the industry. However, it is also true that lots of blockchain startups and professionals have started to leave the industry for various reasons, ex.) difficulty to monetize, their own company policy and etc…

For this reason, we realized the number of people in the Japanese blockchain industry has been gradually decreasing. Plus, we found that the environment in Japan for a new-comer to the industry was not well developed enough. In other words, though we have so many communities/events, there is not a clear enough path for non-blockchain to get more deeply involved in the industry. Maybe some event/seminar for beginners exists, but we don’t think there are enough.

We are very glad we eventually gathered over 100 hackers. And, we would like to say thank you to our awesome sponsors and venue provider Speee inc!

Here’s our recap of the exciting two days!

Day1 Throwback— TechTalk by Blockchain Specialist Sponsors

1.Yusuke Obinata a.k.a. Obi, Founder of NodeTokyo, CryptoAge
Theme：Introduction of Blockchain

2. Kazumi Hirose, Prince of Deployment at Microsoft
Theme：What Microsoft is doing with blockchain, Develop DApps using Azure Blockchain Service

3. Jeff Wentworth Co-Founder of Cruvegrid
Theme：Architecting Enterprise Blockchain Applications

4. Jun Katagiri, Senior Architect of LayerX inc.
Theme：Smart Contract with Vyper

5. Shogo Ro, Blockchain Division Manager at Sun*
Theme：Mass Adoption of Blockchain

6. Ryohei Komiyama, Co-Founder & CTO at Kyuzan Inc.
Theme：What Front-end means for a blockchain engineer

7. Hirohumi Aoki, Head of Blockchain Business at Metaps
Theme：How blockchain engineers should choose from various technologies

8. Shohei Yoshida・Tomoya Kita, Software Engineer at Mobile Factory/Uniqys Kit
Theme：How to utilize Qurage Link・What is Uniqys Kit and how to develop DApps

9. Kasima Tharnpipitchai, Director of Engineering at OmiseGO
Theme：The Path to More Viable Plasma

10. Anton Buenavista, Senior Developer at Kyber Network
Theme：Enabling Decentralized Finance

11. Asuka Nishide, Co-Founder/CTO at FiNANCiE
Theme：Collaboration between on-chain and off-chain

12. Yuki Tanaka, Vice President at Recruit Strategic Partners
Theme：Blockchain Startup Investments and Trends

13. Richard Ma, CEO at Quantstamp
Theme：zk-STARKs, an Introduction

14. Xan Ditkoff, Takato Tomizawa Production Partner at Blockcstack, Engineering at Blockstack
テーマ：Introduction of Blockstack Platform

15. Bill Laboon, WEB3 (Presented by Obi)
テーマ：Introduction of WEB3

DAY2 — Looking back on the hackathon ＆Presentation・Results

This time, we set a very general product development goal so beginner and intermediate blockchain hackers could build something.

1. Developing a prototype for a service using blockchain and/or smart contracts
2. Developing a prototype for a Dapp with extremely high usability

We believe, while these two themes are very fundamental, they play an important role when we consider the implementation of blockchain applications.

In addition to the above criteria, all of the judges considered 4 points:

Originality:
4) The idea is new to the world
3) The idea is new to me
2) The idea is adapted from a different domain
1) The idea has been adopted already in the blockchain industry

Technical Feasibility
4) Prototype/Demo is working seamlessly and future plans to scale are well thought out, the architecture makes it easy to build on top of
3) Prototype/Demo is working seamlessly
2) Prototype/Demo is half working
1) A tutorial level simple implementation, any competent engineer can easily build this within a few hours

Usability
4) Intuitive for users to learn and use
3) Easy to use after some learning
2) Complex but still usable after some learning
1) No usage unless a lot of time is spent for learning

Social Inpact
4) Potential for the outcome of this project to make a significant impact beyond the presented field
3) Potential for the outcome of this project to make a significant impact within the presented field
2) Low potential to address an important problem or a critical barrier to progress in the presented field
1) This project is not considered impactful

Here, we introduce projects of the top winning teams. Please refer to Cryptocurrency Watch for further details.

2nd Runner Up — “COME-ON!!”

2nd Runner Up was awarded to team “COME-ON!!”. They developed a blockchain based platform for SNS campaign or promotion so as to make visibility and transparency whether payments or some shape of rewards are actually being made.

1st Runner Up — “MYPAYPAY”

1st Runner Up was awarded to “MyPAYPAY”. They developed a blockchain based salary payment platform, named Smart Salary.

Winner — “Virtual Grave Game”

First place was awarded to “Virtual Grave Game”. This project creates a virtual grave space combined with NFT. They implemented a cryptocurrency tipping system so anyone could donate or tip to somebody already dead as we do in the real world. This was a very novel concept with interesting gamification features.

We also prepared several special awards, and 7 teams ultimately received awards. Each team developed DApps making use of their unique ideas.

If Decrypt Tokyo made you more interested to get involved in the blockchain or at least taught you know more about the blockchain industry, we are very happy.

So, Thank you again for participating in Decrypt Tokyo 2019! Maybe (or hopefully) we see each other NEXT YEAR in Decrypt Tokyo 2020.

— From All of Quantstamp/Quantstamp Japan Team Member

Quantstamp Japan organized Decrypt Tokyo 2019, a blockchain hackathon in Japan was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Quantstamp we are interested in pushing forward smart contract security. Our newly released Betanet is helping to secure contracts in the wild, but we think there is still work to be done.

The Need for Assurance

Existing solutions — the Quantstamp Betanet included — focus largely on pre-deployment security checks. Such checks don’t guarantee that a smart contract cannot be hacked in the future. Once a contract is deployed on mainnet, it may still contain subtle bugs which leave it open to attack; after all, Ethereum contracts are immutable. Automated checks are great, but may contain false positives or false negatives, and while manual white-glove audits are better, they are still subject to human error. Moreover, novel attack vectors present themselves as the technology matures and attackers spend more and more time determining how to exploit weaknesses in a platform.

Providing a sense of assurance for contracts that have been deployed on the mainnet fills a gap in the current smart contract security ecosystem. Assurance of deployed contract correctness has been a goal of Quantstamp since we began on our mission, including as described in the whitepaper. To this end, we’re proud to present the Quantstamp Security Assurance Protocol.

The Quantstamp Security Assurance Protocol

The Quantstamp Security Assurance Protocol aims to allow users, which we will call pool owners (for reasons that will become clear below), of a deployed smart contract to de-risk the potential negative consequences of a security incident. Assurance would be provided by both security experts and non-experts who are incentivized to understand and assure the security, safety, or other performance characteristics of a smart contract.

How it Works

IMPORTANT CAUTION: “How It Works” and the content in this post are provided for informational purposes only and describe our current vision and design aspirations for the Quantstamp Security Assurance Protocol and platform and functionality of QSP tokens. Potential features, functionality, schedules, implementation, testing environments, and/or design architectures are subject to continuing update, modification, cancellation, delay, external dependencies, third-party operators, third-party platforms, evolving regulatory frameworks, and/or factors beyond our control. You are cautioned not to place undue reliance on this information. FOR AVOIDANCE OF DOUBT, THE INFORMATION, PROTOCOL, PLATFORM, AND ACCESS AND/OR USAGE THEREOF, INCLUDING ANY ASSOCIATED SERVICES OR MATERIALS, SHALL NOT BE USED, CONSIDERED, OR RELIED UPON AS ANY MANNER OR FORM OF INVESTMENT, INVESTMENT PURPOSE, VEHICLE WITH AN EXPECTATION TO EARN A PROFIT, OR FINANCIAL, INVESTMENT, TAX, LEGAL, REGULATORY, OR OTHER ADVICE.

A CCR is a Centralized Curated Registry. Quantstamp will maintain a list of security experts.

The Quantstamp Security Assurance Protocol is designed to enable smart contract users (and other pool owners) periodically reward security experts (and other people willing to assure the security and safety of a smart contract in return for compensation) for their skills in assessing the security of contracts that pool owners care about. For the sake of simplicity, we will consider only pool owners who are users of some contract. Similarly for the limited purpose of this illustrative discussion, we will assume everyone who is willing to assure the security and safety of a smart contract is a security expert (or simply, an expert).

In this service marketplace concept, a concerned smart contract user incentivizes security experts to stake collateral through the Quantstamp Security Assurance Protocol. The value of the collateral is determined by the user, who must estimate for themselves the cost of the contract’s failure to operate as expected. For example, if the contract holds a user’s deposit, the user may ask for a collateral whose value is equal to their deposit. If this community stakes such a collateral, the user promises to periodically reward the community, provided the smart contract continues to operate as the user desires. If the contract misbehaves, the experts instead relinquish their staked collateral to the user according to the terms set by the user. This mechanism is intended to compensate the user for the loss of funds or other damage they may suffer from the contract misbehaving.

The Quantstamp Security Assurance Protocol user must provide a suitable definition of the behaviour of the smart contract that they wish to avoid. The Quantstamp Security Assurance Protocol will incentivize security experts to analyze the contract and determine if it will ever operate in an undesirable way, according to the definition provided by the user.

Note that, before deploying a smart contract, users could instead pay for an expensive audit, but this may not be possible or helpful. Simply put, if the audit fee is too high, then they’re out of luck. Instead, the protocol enables an incentive to security experts and community members in the form of a periodic reward distributed over time, which may result in a significantly smaller up-front cost for the user, as in the example below. Even if an audit is affordable, audits usually ask for things not available on the blockchain: test cases and design documents, which users do not generally have access to. Community members may not require these documents to assert that a contract is safe to use.

Example

This is an illustrative example of the latest version of the UI for the Security Assurance Protocol. This UI may change in the future.

Plasma is a framework that can be used by application developers in order to increase transaction throughput. Lukas Schor (of Argon) summarizes it nicely: “Like payment channels in the Bitcoin Lightning Network, Plasma is a technique for conducting off-chain transactions while relying on the underlying Ethereum blockchain to ground its security.” Plasma achieves this functionality via a plasma operator who runs a plasma chain which handles the transactions between plasma participants. Plasma chain block headers are periodically published on the Ethereum network. Users can deposit funds to, or withdraw funds from the plasma chain via a root contract, which is a smart contract on Ethereum.

Users join the plasma chain through the root contract, either directly or through some interface provided by a decentralized application. If the root contract is hacked, users may lose assets.

The current state of specification for the plasma framework is that it is underspecified at worst, or varied and overwhelming at best, plasma contracts are complicated and hard to get right. Naturally, as a mere framework, plasma does not require that a root contract be audited. Given the combination of complex code with the potential storage of assets with significant value, plasma contracts will be an alluring target for attackers.

The users for an application implementing a plasma chain may wish to have some assurance that this undesirable scenario isn’t possible, or that they get some compensation if it occurs. Compensation is desirable because it reduces the potential loss incurred by using a plasma chain that is attacked.

For simplicity, assume that a user U uses some application which uses a plasma chain for which the root contract is R.

User U can use the Quantstamp Security Assurance Protocol to get additional assurance that R will continue to operate as U wants it to operate, even if U is not R: i.e., U is assured that someone else’s smart contract will work correctly. It allows smart contract users to receive assurance that a contract they rely on won’t misbehave, even if they didn’t write the contract themselves. In addition, the Quantstamp Security Assurance Protocol enables a service marketplace for security experts to sell their skills, by assessing the security of contracts that pool owners care about. IMPORTANT CAUTION: While we are continuing to explore design architectures through testing and learning, QSP tokens as currently envisioned in this protocol should be acquired and utilized solely for the purposes of prepaying for and consuming security services and performing the functionality of the associated staking without any reasonable expectation of profit in QSP tokens as an investment vehicle.

User U achieves this as follows: U asks the community to stake a certain amount of QSP through the Quantstamp Security Assurance Protocol. If the community stakes this value, U promises to periodically reward those who participate, provided R continues to operate as U desires. In order for this to be possible, U must provide a suitable definition of the behaviour of R that they wish to avoid. This incentivizes the community to investigate the contract R to determine if R will operate in an undesirable way, according to the definition provided by U. User U sets the terms of compensation in case the community is wrong.

For example, U could ask that the community stake 1,000,000 QSP to claim that R will not have a zero balance ( e.g., it has been hacked — since U knows it will always have at least the balance U deposited, provided U has not withdrawn their deposit) for the next 1,500,000 blocks. In turn, U will pay a total of 10,000 QSP every 125,000 blocks (about 28 days, assuming 20 seconds per block), split amongst those who staked their QSP. On the other hand, if R’s account drops to zero, U will be able to claim 1,000,000 QSP from all the stakes made by the community. After 1,500,000 blocks (about 347 days), the payments from U will stop, and the community can reclaim their staked QSP. If there’s no hack and R continues to operate as intended, the community has successfully put their QSP to work.

In the use case above, the user U is a pool owner of R, and community members who stake are called assurance providers. The Quantstamp Security Assurance Protocol allows arbitrary pool owners to ask for a stake by arbitrary assurance providers, and to set their own terms. Pool owners will be free to set the behaviour that is undesirable, the amount they’re willing to pay assurance providers (and the rate at which they do so), and the amount they wish to claim in the event that the undesirable behaviour occurs.

“Undesirable behaviour” will be automatically checked by the Quantstamp Security Assurance Protocol when participants wish to withdraw funds. In short, it’s going to be the result of a function call on a policy contract defined by the pool owner. Since the pool owner will define that contract, it’s going to be a case of “buyer beware” — pool owners may put backdoors in the policy.

In order to mitigate backdoors and malicious policy contracts, the Quantstamp Security Assurance will point to a list of security experts whose lead other assurance providers can follow for questionable policies. The Quantstamp Security Assurance Protocol will point to a Centralized Curated Registry (CCR) which will hold a continuously evolving list of addresses of community members who have demonstrated themselves to be security experts. Security experts who stake that a contract is secure — which is to say, will perform as expected — will gain a larger share of the periodic payment provided by the pool owner. Security experts who stake earlier than others will earn even more; this discourages other experts from simply bandwagoning after another expert who actually checks the contract. Of course, if experts on the CCR stake on insecure contracts, they shouldn’t expect to stay on it for long.

And of course, pool owners will be able to link to an audit report if they have one, to enable assurance providers to make as informed a decision as possible when deciding whether or not to put their QSP on the line.

In short, the Quantstamp Security Assurance Protocol is designed to assure users of a smart contract of its behaviour by asking security experts to stake collateral against the claim that it will misbehave. Assurance could be available even when the user didn’t author the contract. Moreover, the Quantstamp Security Assurance Protocol would allow security experts to put their QSP to good use and receive income for services based on their skills.

The Quantstamp Security Assurance Protocol is in development now after months of research, and we’re aiming to release the first pilot version in the upcoming months.

This post was authored by Blockchain Researcher Jan Gorzny, (Ph.D Candidate) with contributions from Senior Research Engineer Sebastian Banescu, Ph.D.

Originally published at quantstamp.com/blog.

A Technical Introduction to the Quantstamp Security Assurance Protocol was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the last eight months, Quantstamp has been developing and completed an alpha test of the Quantstamp Security Assurance Protocol (QSAP). The goals of this project include helping to increase confidence in the security of deployed smart contracts and mitigating the risk of losses due to security vulnerabilities. This effort is motivated by the inexorable reality that smart contracts may be exposed to unforeseeable attacks during the post-deployment stage, when the code is immutable.

We’ve mentioned QSAP at KAIST University and the KryptoSeoul Meetup in South Korea, the Fields Institute in Toronto, the Ethereum Berlin meetup, and multiple times during our monthly Telegram AMA (now hosted on Reddit). Still, it’s likely that some of our readers need an introduction.

IMPORTANT CAUTION: The content in this post is provided for informational purposes only and describes our current vision and design aspirations for the Quantstamp Assurance protocol and platform and functionality of QSP tokens. Potential features, functionality, schedules, implementation, testing environments, and/or design architectures are subject to continuing update, modification, cancellation, delay, external dependencies, third-party operators, third-party platforms, evolving regulatory frameworks, and/or factors beyond our control. You are cautioned not to place undue reliance on this information. FOR AVOIDANCE OF DOUBT, THE INFORMATION, PROTOCOL, PLATFORM, AND ACCESS AND/OR USAGE THEREOF, INCLUDING ANY ASSOCIATED SERVICES OR MATERIALS, SHALL NOT BE USED, CONSIDERED, OR RELIED UPON AS ANY MANNER OR FORM OF INVESTMENT, INVESTMENT PURPOSE, VEHICLE WITH AN EXPECTATION TO EARN A PROFIT, OR FINANCIAL, INVESTMENT, TAX, LEGAL, REGULATORY, OR OTHER ADVICE.

What we mean by “Security” and “Assurance”

Both security and assurance are important words in this discussion, so let’s start there.

Security, in the sense that loss of digital assets encumbered by a contract are protected, to some extent, by the collateralized staking of QSP tokens by a set of project advocates, many of whom are themselves security experts. These advocates stake their own QSP tokens based, ideally, on a reasonable belief that the contract is secure. More precisely, we reduce the meaning of a secure contract to be one whose policy is never violated. (More to come regarding the term policy.)

Assurance, in the sense of having confidence that the contract will be executed in the expected manner for its practical lifetime. Note that we postulate that QSAP can be used to increase assurance in the security of a project, but not as a guarantee.

IMPORTANT CAUTION: While we are continuing to explore design architectures through testing and learning, QSP tokens as currently envisioned in this protocol should be acquired and utilized solely for the purposes of prepaying for and consuming security services and performing the functionality of the associated staking without any reasonable expectation of profit in QSP tokens as an investment vehicle.

Pool Owners and Assurance Providers

We call the two principal actors in the protocol pool owners and assurance providers. QSAP connects stakeholders of projects with security experts and project advocates who are willing to stake their own QSP tokens to cover potential losses as an initial step towards providing assurance services.

Pool owners are those who have a vested interest in the security of a project; these may include the owners of a multisignature wallet, the legal entity or community who launch a dApp, the participants in a DAO, a decentralized exchange, and so on. The pool owners all have something to lose when some unexpected or malicious behavior occurs.

Assurance providers, who risk their own QSP tokens as collateral on the security of the project, and are rewarded with pool owner defined service payments in the form of QSP tokens. Thus, an assurance provider is rewarded through QSP tokens usable to further support their efforts to be a reputable assurer who rationally assesses risk. Assurance providers are project advocates who may or may not be security experts, and who have rationally decided to risk their own funds.

Staking implies risk because, should the assurance provider incur losses due to an undetected security vulnerability, it is the assurance provider who forfeit their funds to the pool owner.

The amount of effort that goes into understanding risk is captured, by a proportionate metric, via the staking of QSP tokens. On the one hand, security experts or malicious hackers, who spend a high amount of effort looking for security vulnerabilities in smart contracts without finding any such vulnerability, will be incentivized to stake a high amount of QSP tokens, because there is no other way in which they will get rewarded for this effort (unless it was a commissioned audit). On the other hand, if security experts or hackers do find a vulnerability, they will exploit it and steal funds from a contract. In that case it is well worth having some assurance as a pool owner; therefore, both scenarios indicate that using QSAP is good for both pool owners and assurance providers, and security experts and advocates can publicly demonstrate their confidence in the project by quantifying the amount of effort and strength of conviction for the project.

By advocating assurance for a project, consider the following:

1. Assurance providers are awarded pool owner-defined service payments in the form of QSP tokens in some quantity proportional to the undertaken risk and level of expertise;
2. Assurance providers, by receiving the award, may choose to undertake a greater risk by performing more security research, using QSP tokens to provision automated scans or other services of the QSP network;
3. Assurance providers, by conducting more security research, may choose to increase the stake by leveraging premiums to further assert their confidence in various projects;
4. Further, the award of QSP tokens establishes crypto-economic incentives for security experts and project advocates to actively engage.

Assurance providers may further use QSP tokens to diversify their commitments of assurance across many projects, thus distributing both the assurance providers’ risk and minimizing the potential losses for pool owners.

The relationship between pool owner and assurance provider is hypothesized to provide increased assurance or confidence that, should unexpected behaviors result in the loss of funds, assurance providers will provide the prepaid staked QSP to be able to compensate pool owners for their losses associated with establishing and defining a pool. Indeed, QSAP programmatically enforces the rules that govern the interactions of these two principal actors, which takes us to the matter of the policy.

Assurance Policies

Policy, a contract that precisely specifies a set of conditions that determine whether or not the security of the project has been compromised.

Policy developers will need to think through the edge cases, and security experts will need to evaluate the correctness and thoroughness of policies very carefully. One could imagine a very simplistic policy wherein security is considered compromised if and only if the balance of Ether stored in the smart contract falls below a certain value. It’s easy to imagine how this could become increasingly complex; for example, what might be some exceptions to this rule? Perhaps it would be permissible for the balance to go below a specified value if and only if a majority of signatories (i.e., in the case of a multisig wallet) agree to withdraw the funds. If that were the case, then the policy should ensure that such a withdrawal does not trigger a security event.

We Need Your Help

Recently, we’ve begun testing QSAP on the Ropsten network and, concurrently, we are developing simulations using smart agents based on reinforcement learning. Some work still needs to be done to better understand how to configure a pool and write good policies. We are presently exploring the amount of expressivity needed for policy developers to be able to capture various scenarios that would warrant the automated recovery of losses. We’re hoping that members of our community will be eager to help, too!

If you’re like us and enjoy “thinking like a hacker,” then you’ve probably already been speculating about how you might game such a system, right? Let’s get that discussion and others rolling along on the Quantstamp subreddit.

We’re excited about QSAP and hope you are, too. There’s still work to be done, and we’d like to invite the community to help us out.

This post was authored by Quantstamp Cofounder Steven Stewart with contributions from Senior Research Engineer Sebastian Banescu, Ph.D.

Note: This update includes information and forward-looking statements about upcoming events and concepts under continuing development. Schedules, features, and functionality are subject to change or cancellation at any time and you are not to place undue reliance on this information or any forward-looking statements.

Introducing the Quantstamp Security Assurance Protocol was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

This year, members of the Quantstamp team and some of our friends participated in the ETHDenver Hackathon. Our CEO Richard Ma, Poming Lee (myself), Nathan Frenette and Derek Alia entered the hackathon as “Beacon Thugs and Harmony” and hacked away at an implementation of the ETH 2.0 Beacon Chain.

The Beacon Chain is Core ETH2.0 Infrastructure

The beacon chain plays an integral role in ETH2.0 infrastructure and is scheduled to be the first part of ETH2.0 to be implemented. One of the functions of the beacon chain is to randomly select a “committee” of eligible validators that propose and validate blocks on both the beacon chain and shard chains. The beacon chain accomplishes this random selection by producing an unbiased, unpredictable and verifiable number through the RANDAO + VDF process.

ETH 1.0 Blockchain: Randomly Selecting Block Proposers in Proof of Work

Generating a truly random number is a challenging problem. It is important that block proposers are selected in a random fashion in order to prevent these same proposers from tampering with blockchain data. In proof of work, this is achieved through brute force. The only way to game the system and enhance your chances of selecting the “golden nonce” is to add more hashpower to the network.

In Ethereum’s planned 2.0 upgrade, Ethereum aims to eliminate proof of work in order to scale transactions and eliminate “redundant” computations by distributing computational work over shards. In order to fairly and securely select block producers without proof of work, Ethereum 2.0 is selecting validators using a random number generated by the RANDAO + VDF process.

ETH 2.0 Blockchain: Randomly Selecting Block Proposers in Proof of Stake With A Random Seed Generated Via the RANDAO + VDF process

In order to fairly select the next committee of validators for Ethereum 2.0, all of the active validators from the current committee participate in a random number generation process in order to produce an “unbiased” random number. The random number generation can be broken up into two parts: the RANDAO and the VDF.

The RANDAO

The RANDAO works via a commit reveal scheme. The current committee of validators each submits a hash of a locally produced secret to the beacon chain. After all hashes are collected, the reveal stage begins: validators submit their locally produced secret to the beacon chain in a predetermined sequence. After each secret is sequentially revealed, the beacon chain performs the XOR operation on the validators revealed secrets. If a validator chooses not to reveal their secret, the beacon chain XORs a 0 in place of their secret.

The Last Revealer Attack

If we just relied on the RANDAO for random number generation, we would be vulnerable to what is known as the last revealer attack. The RANDAO has entropy that can be biased by the last validator to submit their secret. The last validator can choose between one of two different random numbers by choosing to either reveal their secret or to hold it.

Using a Verifiable Delay Function to Counter the Last Revealer Attack

Without the Verifiable Delay Function (VDF), the last revealer can bias the selection of the next committee of validators that will finalize blockchain data. In order to prevent this attack, the beacon chain submits the entropy produced by the RANDAO algorithm into the VDF.

The VDF is an algorithm that uses the biasable random number generated by RANDAO as an input to generate an output that is a truly random number. The VDF accomplishes this by putting the RANDAO’s biasable random number through a series of computations that intentionally take a long time to generate the output. The VDF intentionally uses time-intensive computations to generate the output so that the last revealer in the RANDAO process can no longer bias the final result.

The Difficulties We Encountered Following the Specification

Initially, our goal was to implement a beacon chain simulator that was 100% based on the specification. However, after realizing that there is no single, complete, detailed algorithmic description to the beacon-chain, we decided to implement the simulator as faithfully as we could to the “spirit” of the information found in the documents.

It took our team, composed of one Computer Science PhD and three professionals in the field, over 50 cumulative hours to come up with a coherent idea of what a beacon-chain is and how it works. During this time, we traced the references listed below, had discussions, guessed the undescribed details, and solved conflicts between the references.

List of References that Helped Us Piece Together the Beacon Chain Spec:

• Devcon4 Mainstage — Justin Drake — YouTube
• Minimal VDF randomness beacon — Sharding — Ethereum Research
• Clearing Up Casper, Proof Of Stake, And Beacon Chain Confusion, Once And For All — ETHNews.com
• Serenity Handbook — Ethereum.org
• https://github.com/sigp/lighthouse/blob/master/docs/serenity.md
• eth2.0-specs/0_beacon-chain.md at dev · ethereum/eth2.0-spec
• ethereum/beacon_chain
• sigp/lighthouse: Ethereum Serenity Client
• eth2.0-pm/README.md at master · ethereum/eth2.0-pm

Presenting Quantstamp’s ETHDenver Beacon Chain Implementation

You can access our beacon chain simulator and the interactive front end we developed for it via the links below:

• Beacon Chain Simulator
• Front End to our Simulator

How to Use Our Implementation to Improve ETH2.0

The development of Ethereum 2.0 is a community effort. In that spirit, we have some suggestions on how you can carry the torch and use our implementation to conduct experiments that can improve Ethereum. Developers can experiment with the parameter set up in order to optimize it or to discover potential security issues. After spending a small period of time reviewing the code, developers can also add or change modules written in the simulator, or make significant modifications that cater to their own understanding of how the beacon-chain should function.

If you conduct an experiment and find anything interesting, please let us know.

Making It Easier for Others to Experiment with our Beacon Chain Implementation

Developers can also improve upon this implementation by making it easier for users to experiment with the parameters setup. This can be done by integrating the front end (GUI) we provided to the back end simulator so that they can work in an online fashion (currently the experimental result is generated offline and should be manually fed to the front end GUI). Improving the back end experimental logic would also be helpful. Adding an auto-setup script for running the entire project locally would also be ideal for experimentation. It will make the simulator a lot easier for developers to play with.

Presenting Quantstamp’s ETHDenver Beacon Chain Implementation was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

What We Learned from Fomo3D — Part 2

Last time, in What We Learned from Fomo3D — Part 1, we were introduced to Fomo3D and talked about how its attempt at random number generation could be exploited.

In order to incentivize players to purchase keys, the Fomo3D smart contract would transfer Ether into a pool dedicated to airdrops then “randomly” assess whether the purchaser was eligible for an airdrop from this pool. Since Ethereum is inherently deterministic, the numbers generated were not truly random, and could be predicted by attackers. In an attempt to resolve the lack of randomness inevitably present in Ethereum, Fomo3D developers prohibited calls by external smart contracts. However, this attempt was naive and exploitable.

Now, we get into the second lesson that Fomo3D taught us, which happened at the end of the first round. Despite the general assumption that the game would be won by a colluding mining pool, it never made it that far. The first round of Fomo3D was ended by a user with address 0xa169df5ed3363cfc4c92ac96c6c5f2a42fccbf85 performed a systematic attack that exploited the greedy behaviour of the Ethereum miners.

When a user submits an Ethereum transaction, the transaction gets broadcasted and becomes part of the so-called mempool of transactions. The miners then select transactions from the mempool and organize them into a block to be attached to the chain via proof of work. The key point to notice here is that the selection of which transactions will be placed in the next block is left at the discretion of the miners. As the behaviour of miners is greedy, transactions that are valuable, i.e., those that consume a lot of gas and whose sender specified the highest gas price, will get packed into blocks before other transactions do. Furthermore, the size of blocks in terms of the maximum amount of gas per block is limited (currently 8,000,000). Therefore, by submitting many transactions that nearly consume an entire block and that yield gas revenue for the miners exceeding the yield of other transactions on the network, the attacker was able to prevent other transactions from getting mined. The user purchased a key in block 6191896. The network blocking happened between blocks 6191898 and 6191906, which was sufficient for the time limit for the next key purchase to lapse. During the attack, the number of transactions per block decreasing from around 100 to less than 10.

The possibility of manipulating transactions was warned against many times before Fomo3D. However, it was always cited as a possibility from the side of the miners. For example, in the Ponzi scheme Governmental, the goal of an investor was to remain the last for at least 1 minute to win the jackpot. Since the timestamp of a block is determined by the miner who attached the block to the chain by the proof of work, and since there is some levy for the accuracy of timestamps in Ethereum, there is space for the miner to manipulate the timestamp and increase their own chance of winning. The Ethereum community was also warned against colluding miners that could actively exclude transactions of other participants from blocks, again trying to become winners on their own. However, the end of round 1 of Fomo3D is the first time when we saw an external user taking advantage of the greedy predictable algorithm for selecting transactions to be mined. Moreover, all they needed to make it happen was some Ether to cover the high gas cost. This is an important lesson for all applications that rely on security mechanisms that require users to submit transactions.

For example, the Ethereum scaling concept Plasma proposes the introduction of a hierarchy of chains. The top-level chain is called the “root chain’’ and governs the lower level chains that are called “plasma chains.’’ The task of plasma chains is to handle a large number of transactions that only once in a while get summarized and recorded on the root chain. From the implementation perspective, the state of each plasma chain is recorded in a smart contract on the root chain.

If users want to transact on a plasma chain, they need first to lock their funds inside of the smart contract on the root chain. Once they are done transacting on the plasma chain, they ask for a release of their funds and leave. Since the root chain smart contract that governs a plasma chain has no visibility of the individual transactions of the plasma chain, it chooses to trust the chain by accepting the summary transactions, unless a user can prove otherwise. This proof of fraud has to arrive within a certain time limit. If it does not, the governing smart contract is free to assume that the fraudulent summary transaction is based on true activity on the plasma chain. And this is the catch — if root chain network is under such a DoS attack, a user can have a very hard time submitting the proof of fraud. The only question is how long would one need to block the network for and whether the result is worth the cost of gas needed for conducting such an attack. Plasma, as well as all other systems whose functionality relies on the need to submit a transaction at some critical moment, have to be implemented with this attack in mind so that the cost of executing it vastly exceeds the benefit.

The story of Fomo3D is now over. The winner of the first round received 10,469 ETH. Given how the win was achieved, it should not be surprising that the second round was much less popular with the winner earning less than 800 ETH (however, 680 ETH was contributed to jumpstarting round 2 from round 1). The game is currently in much later round with the pool containing just a bit over 1.2 ETH. The trend of dying is obvious here. Nevertheless, Fomo3D will remain a chapter in the history of Ethereum. It made its dent, it attracted the attention of many people, and most importantly, it gave the world another lesson in blockchain security.

Next…

For more content like this, be sure to get on our mailing list and join our Telegram.

Other relevant reading

https://etherscan.io/address/0xa62142888aba8370742be823c1782d17a0389da1#code

https://ethresear.ch/t/alert-will-fomo3d-destroy-ethereum/2630

https://www.reddit.com/r/ethereum/comments/916xni/how_to_pwn_fomo3d_a_beginners_guide/?utm_source=amp&utm_medium=comment_list

https://medium.com/coinmonks/how-the-winner-got-fomo3d-prize-a-detailed-explanation-b30a69b7813f

https://hackernoon.com/a-comprehensive-solution-to-bugs-in-fomo3d-like-games-ab3b054f3cc5

https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620

What We Learned from Fomo3D — Part 2 was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

What We Learned from Fomo3D — Part 1

Fomo3D is a Ponzi scheme smart contract on Ethereum address 0xa62142888aba8370742be823c1782d17a0389da1. The scheme runs in rounds and convinces users to invest Ether in the game while hoping for high returns — the last investor in each round gets the jackpot. In order to become an investor, the users purchase so-called “keys’’ that signify their participation in the game. Every purchase of a key prolongs the duration of the round.

The Fomo3D smart contract was published on Ethereum on July 6, 2018, and very quickly became popular. When its balance exceeded 17,000 ETH, the Ethereum community became interested in the impact of Fomo3D on the network, the Ethereum ecosystem, and formulated some predictions about the future of this scheme. The most viable predictions were that Fomo3D will keep accumulating Ether until the moment when the balance becomes too appealing to the large mining pools, and that those will start colluding in the effort to win the game. Another notable prediction was that the game had the potential of destroying the Ethereum mainnet by consuming all (or at least a great majority of) the Ether in the world that will eventually be all transferred to the hands of a single winner. None of the above happened though. The game was won through an elaborate Ethereum mainnet attack on August 22, 2018, yielding the winner 10,469.66 ETH.

There are two notable events that happened during the first round of Fomo3D that are very interesting from the smart contract security perspective. The first relates to a vulnerability that was introduced in the Fomo3D by the development team. In order to encourage participants to purchase keys, the smart contract would with every purchase of a key transfer 1% of the incoming Ether into a pool dedicated to airdrops. With every purchase over 0.1 ETH, it would “randomly” assess whether the purchaser is eligible for an airdrop from this pool. Unfortunately, the “randomness” was not very random. Rather than generating a true random number, the smart contract performed a deterministic computation based on several seeds taken from the current state of the blockchain.

Before we go any further, let us state that there is no such thing as random numbers on Ethereum. The existence of random numbers would contradict the fundamental principles of the network. Ethereum computations are performed by every node locally (while following the definition of the Ethereum Virtual Machine), and every such node locally maintains the state of the network. The global state of Ethereum is maintained through a decentralized consensus on what computations should have been performed and what the inputs for those computations were. If there was an option for the nodes to generate random numbers, there would be no consensus of the global state. Therefore, all computations on Ethereum must be deterministic and randomness a feature cannot exist.

As mentioned, the authors of Fomo3D decided to derive “randomness’’ from the current state of the blockchain by performing computations on block.timestamp, block.difficulty, block.coinbase, block.gaslimit, the timestamp of the block, the block number and msg.sender. It is true that some of these values are hard to predict when a user submits a transaction to the network (because the user does not know in which block the transaction will be mined), but they are all known at the moment when the transaction computations are being carried out. This means that if the user creates a proxy smart contract, such it can first evaluate all these seeds, replicate the deterministic computations that produce the “randomness,” and based on the outcome decide whether it should make an external call and trigger the transaction for real.

We can demonstrate the issue on a game contract (simpler than Fomo3D) shown below. The contract allows two players to enter in a game, each with 1 ether. After this happens, the first player to enter is expected to call a method for rewarding the winner. The winner is selected based on the hash the current block: the first player wins if the block hash is even, otherwise the other player wins. The winner receives the balance held by the smart contract (2 ether).

The first player can implement a proxy contract shown below that allows for both signing up as a player, as well as calling the rewardWinner() function. However, before calling the rewardWinner() function, the contract can check the block hash, determine who the winner will be, and whether it is beneficial to trigger the function now, or leave it for a later block. Thus, this contract never loses.

In order to battle the possible exploit, the developers of Fomo3D decided to prohibit purchases that do not come directly from an externally owned account (i.e., not a smart contract).

For this purpose, they used the EVM assembly instruction extcodesize(_address) that returns the size of code associated with an Ethereum address. They assumed that code size of a smart contract is never 0. Unfortunately, this assumption is not valid throughout the entire lifecycle of a

smart contract. Specifically, if extcodesize(_address) is invoked from the constructor of the contract on address _address, it returns 0. This is because the contract is still being constructed and does not exist on the blockchain yet (even though it is already executing some code). Therefore, require(extcodesize(msg.sender) == 0) is not sufficient to guarantee that msg.sender is not a smart contract.

This is everything that one needs to attack the airdrop feature of Fomo3D. By implementing a smart contract that inside of its constructor checks that the seeds yield the desired “random” outcome, one can purchase keys only when airdrops are guaranteed. If the airdrop value exceeds the cost of purchasing the key, the whole purchase results in a positive amount of Ether arriving at the user’s account.

Let us for a moment think about how one would implement such a feature correctly. The authors of Fomo3D attempted to resolve the lack of randomness by prohibiting the interactions with smart contracts, but failed to do so. While there is a way of restricting method from being called by other contracts (this method is require(msg.sender == tx.origin)), we should realize that this is not a way to go in general. If you ever find yourself in a situation where calls by other contracts can hurt and you would like to avoid them in the name of security, it is time to rethink your design. The capability of smart contracts acting on behalf of users is an intended feature of Ethereum. Preventing such interactions limits the usability of your smart contract. For example, since Ethereum does not have native support for multisig accounts, any multisignature

wallet needs to be implemented as a smart contract. By prohibiting calls by external smart contracts, one effectively prohibits calls from multisignature wallets (and all other similar smart-contract based dapps).

But back to correcting Fomo3D. We already know that there is no such thing as random numbers on Ethereum. Fortunately, there is an architectural pattern that one can resort to and that gets fairly close to randomness. In this pattern, we break the interaction with the feature that requires random numbers into two steps. In the first step, the caller (possibly a smart contract!) commits to an action. Then, at some point later in the future, they make another call. This future call will be the source of randomness for the event that the caller already committed to.

So, unless the user can read the future (which in the blockchain language mean having enough computing power to be able to produce proof of work for several blocks in advance), they do not have any means of predicting the value beforehand. Furthermore, the number of blocks that have to be mined between the commitment and resolving the event is variable. The more blocks the developer requires, the more computing power an attacker would need to learn the state of the future state blockchain at the time of the commitment.

Next…

Check back next week as we get into the second lesson that Fomo3D has taught us. And for more content like this, be sure to get on our mailing list and join our Telegram.

What We Learned from Fomo3D — Part 1 was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Nadir Akhtar

This document is an overview of the Betanet release — version 0.1.0 of the Quantstamp protocol. Future iterations of the protocol will include more focus on decentralization and handling private audits. However, in the meantime, this iteration is a first step towards achieving those goals.

Table of Contents

Introduction

• The Need for Smart Contract Security
• Smart Contract Audits
• The Quantstamp Protocol
• FAQ

Design Overview

• Protocol Summary
• Protocol Process
• Protocol Breakdown

Contract Architecture

• QuantstampAudit
• QuantstampAuditData
• QuantstampAuditView

Introduction

What is the goal that the Quantstamp protocol accomplishes?

The aim of the Quantstamp protocol is to create a decentralized platform for automated smart contract security audits.

The Need for Smart Contract Security

Smart contracts, enabled by blockchain technology such as Ethereum, have the potential to revolutionize whole industries. However, their immutable nature and automatic execution mean security is essential. This was made clear a year after Ethereum was released by a hack of The DAO.

The DAO was a decentralized autonomous organization implemented through smart contracts which formed an investor-directed venture capital fund. In June 2016, a hacker exploited a vulnerability in The DAO’s smart contracts to siphon off a third of its funds — more than $50 million USD at the time. The DAO hack impacted a large number of people in the Ethereum community and led to a growing realization of the importance of smart contract security.

Smart contract development is considerably different from traditional software development. Rather than working with a database under your own control, decentralized applications (DApps) deployed on the blockchain are immutable, visible to everyone with access to the blockchain network, usually have control over significant amounts of capital, and present an immense attack surface. Even the smallest errors in the contract code can result in catastrophes. It’s clear that security is of the utmost priority when developing and deploying smart contracts. To achieve security guarantees, it’s necessary to perform an audit of the project before launch.

Smart Contract Audits

A smart contract audit is a thorough inspection of an individual smart contract or smart contract project to help ensure that the code cannot misbehave in any way and cannot be misused by an attacker. This means looking not only for common vulnerabilities such as integer overflow and memory mismanagement, but also more involved vulnerabilities usually encountered in systems programming, such as race conditions. In addition to software vulnerabilities, smart contract audits must also investigate game theoretical security, avoiding misalignment of incentives which could allow an actor to gain an unfair economic advantage even though they’re technically following the contract logic.

Audits as part of the quality assurance process for software are not a new concept, but the budding blockchain landscape has relatively little experience analyzing the security of these types of distributed, highly adversarial systems. Security experts in the blockchain space often learn about the best security measures ad-hoc, either as a painful lesson after a hack, or from benevolent white-hat hackers who publish vulnerabilities they discover.

Because of the complexity of performing thorough smart contract audits, most audits are done by security specialists. These specialists manually analyze smart contracts for any bugs, issues, or other unexpected behavior. Given the depth of examination required for even a single project, these manual audits are often difficult to scale.

After years of manual audits and many devastating hacks, researchers began to discover common patterns to smart contract vulnerabilities. To quicken and secure the audit process, they began to create automated tools to assist manual auditors. These tools automate the detection of well-known vulnerabilities, giving human auditors the opportunity to focus on more complex security issues. Given the fledgling status of many of these tools, however, errors are common. Manual inspection is still necessary to help detect and eliminate false positive or negatives, and correctly interpret the findings of these automated tools.

As automated tools get smarter, manual audits may become a smaller part of the audit process. With automating audits, you might be able to detect most known vulnerabilities without much human inspection. In that case, all you need to do is run the tool, or ask someone else to run it for you, and read the automatically generated report. You can then show that report to the world to prove the security of your smart contract project.

However, one major problem arises: how do we ensure the tool is run correctly? How do we prove the authenticity and trustworthiness of the report itself? A malicious actor could decide to hide certain vulnerabilities with the hopes that no one else will investigate further. To increase the legitimacy of the actor’s claim that all vulnerabilities detected by the tool have been revealed, a trusted third party must run the tool and report the findings.

Unfortunately, third parties are subject to similar incentive misalignments — they may have an incentive to keep vulnerabilities secret or may collude with the audit requestor. Someone serving as a white knight, auditing contracts to confirm the findings of these third parties, will not get compensated for volunteering to keep everyone safe. Is there a way to ensure that these automated tools can be run securely while still compensating the auditors?

The Quantstamp Protocol

The issue of providing trustworthy, automated third party audits is the very problem the Quantstamp protocol seeks to solve. It leverages blockchain technology to create a platform for both audit requestors and auditors, providing trusted vulnerability detection for audit requestors while simultaneously giving proper compensation to auditors.

Requestors can submit audits to this decentralized platform and get a reliable audit report without having to know or trust the auditors directly. Auditors running automated software can earn compensation for performing reliable audits. This decentralized platform reduces the chances of censorship and collusion significantly by removing the need to trust in any individual entity.

FAQ

What is the benefit of using the Quantstamp protocol to audit my contract versus running automated smart contract analyzers myself?

Automated smart contract security analyzers are currently relatively difficult to setup and use correctly. Those with the ability can indeed perform their own automated smart contract audits using these tools or even install the Quantstamp protocol software and spin up their own private blockchain. However, you will be missing out on the crucial aspect of the protocol: the validation and consensus around the results of your audit. Sure, you can claim that your automated analysis of your own contract showed zero vulnerabilities, but to anyone else who you’re trying to convince, that would sound a tad… fishy. And even if you report that your own analysis has discovered some vulnerabilities, who’s to say you’ve shared them all?

While you can run your own automated audit or even spin up your own version of the protocol to prove to yourself your contracts are bug-free, others may not trust your findings. To prove to the world the security of your contract, it’s necessary for a third party to independently verify that your contract is free of vulnerabilities. Blockchain networks, in particular, earn additional trust by making it difficult to impossible for any two parties to collude.

Aside from the trust issues with running your own automated audit, there are technical barriers as well. You’ll need to understand how to install and operate these tools — no trivial feat. Also, you will need sufficient computational power to run the auditing tools or protocol.

Are there any benefits of an audit done through the Quantstamp protocol compared to a manual audit?

With a manual audit, a small team of auditors is looking for vulnerabilities by hand. What’s to say that these auditors aren’t bribed into keeping some vulnerabilities secret? Their reputation would be at stake, but perhaps they’re confident enough the vulnerability won’t be detected by anyone else.

While corruption within reputable auditing companies is highly unlikely — a threshold low enough for most project teams, exchanges, observers, and so on — there still does not exist a 100% guarantee of integrity.

On the other hand, an audit done through the Quantstamp protocol is a set of automated tools running on several different devices across the world. What we want the most out of an automated, decentralized audit is not just the results themselves since we could get the results by running the tools on a private network, but rather the results along with proof that the results are valid and not manipulated. (A side benefit to automated audits through the protocol is its reduced cost relative to manual audits.)

Won’t performing an audit on my smart contract through a public protocol expose my code and intellectual property to the world?

In order to use the Quantstamp protocol, you have to submit your code to a publicly facing network. Your smart contract code will, therefore, be exposed for analysis by third parties. This will provide a highly trustworthy audit of your code and will also allow others to verify that the audit was of your code in particular. However, it does expose your code to the world.

If privacy and IP protection is a concern, you may choose to do an audit on a private network or hire security experts to examine your code privately. However, you will miss out on the ability to prove to the world that your code has gone through an automated and decentralized smart contract audit.

Design Overview

The following section will go over the design of the Quantstamp protocol. While this is accessible to all readers, it will only be of interest to those looking to understand the lifecycle of an audit as it moves through the protocol.

Protocol Summary

The QSP protocol consists of three main participants: the Requestor; the Contract, also known as the Protocol; and the Audit Node.

A Requestor, looking to request an audit, sends the smart contract to audit and payment to the Contract. An Audit Node accepts that request and generates a vulnerability report using automated tools. The Audit Node sends back to the Contract the report and receives compensation. The Requestor now has access to the vulnerability report.

Here’s a closer look at what the process looks like.

Protocol Process

The audit goes through a few possible states, as demonstrated by the state machine diagram below. (A state machine is a way to describe the transformation of something through a process. In this case, it describes an audit. Each circle represents a possible state of the audit, and each arrow represents a function of the contract.)

Here’s a breakdown of the possible states of the audit:

• None: The audit does not yet exist.
• Queued: The audit has been requested by a Requestor.
• Expired: The audit timeout period has been passed.
• Assigned: An Audit Node has successfully picked up the audit.
• Completed: the report was submitted in time with no error.
• Refunded: The Requestor has received a refund for a service not performed in the alloted time.
• Error: There was some issue with producing the report for the user.
• Resolved: The owner of the contract has resolved the error manually.

Naturally, the desired flow is None ==> Queued ==> Assigned ==> Completed. This is the “happy path” in which the Requestor’s audit is performed and the Audit Node receives compensation with no issues. Issues regarding timeouts or processing errors are undesirable but handled by the protocol in the other paths.

In the next section, we’ll take a deep dive into each step of the protocol.

Protocol Breakdown

The first step to requesting an audit is for the Requestor to acquire QSP, the Quantstamp protocol token, to purchase services from the Protocol.

Once the Requestor has QSP, the next step is giving the Contract an allowance of tokens. This is not a transfer of tokens; instead, the Requestor is allowing the Contract to transfer some amount of tokens out of the Requestor’s account at its discretion. This is standard ERC20 token functionality built precisely for this purpose. There is no fear of tokens being transferred out of the account unexpectedly, as the Requestor can examine the contract’s functionality before giving the Contract an allowance. Giving an allowance is necessary because it is not presently possible to securely call a function with a token transfer() call. This particular contract will only draw the tokens from the account when an audit is being requested.

The third step is requesting an audit, providing the contract code to the Quantstamp website. From there, the website will compile the code, turn it into a link, and pass that link back to the Requestor. (A note: while directly interacting with the protocol contract is an option, the web interface provides a comfortable UI for interacting with the contract and will be highly preferable for most users.) The Requestor can then submit that link back to the contract via requestAudit(). From here, a requestID will be generated for the Requestor, and the audit request will be Queued. During this time, the QSP will be held in escrow by the contract, awaiting either a completed report or an error resolution before paying out.

From there, the Requestor will be waiting until the state of the audit changes. An Audit Node will ideally pick up the audit, at which point the state of the audit will become Assigned. If the audit is not picked up in time, it will then become Expired, allowing the Requestor to call refund() to reclaim their QSP.

If the audit is in the Assigned phase, the assigned Audit Node is expected to process the audit before the timeout. If the report is submitted in time, then the state of the audit becomes Completed. Else, if the report is submitted too late, then the audit will be Expired and redeemable for a refund.

Though it is not expected to be a common occurrence, there is the possibility of an Audit Node experiencing an error. In this scenario, the Audit Node will submit an Error status to the Contract, and Quantstamp will manually resolve the issue to decide whether the Requestor receives a refund or the Audit Node receives compensation for the audit.

Contract Architecture

The protocol is designed to meet the following goals:

• Requestors submit audits with payment and receive reports in return, or a refund if a report is not submitted in time.
• Auditors receive audits with the promise of payment in the scenario where a report is properly reported.
• All this functionality is handled securely and efficiently.

To achieve this, the project logic and data is split between three contracts:

• QuantstampAudit.sol: The logic portion of the project. This contract contains all logic and data relevant to the particular decisions of the protocol.
• QuantstampAuditData.sol: The storage portion of the project. This contract contains all data meant to persist between all versions of the protocol, such as audit requests.
• QuantstampAuditView.sol: The data interface portion of the project. This contract serves only to give access to information about the protocol’s data, primarily meant to be accessed by a web application through web3.

Splitting this logic between three contracts facilitates upgrades to the protocol. All information on a blockchain is immutable, meaning that it’s impossible for anyone, including the contract deployer, to modify a smart contract once on the blockchain. What should be done if an upgrade is needed?

This question brings up several more. If we create a new contract with our desired capabilities, what happens to the previous contract? And what happens to any information stored within the previous contract? Is it lost? Must the new contract start from scratch?

With separate contracts for logic and data in our protocol, we make it possible to smoothly upgrade both logic and data. When the protocol’s logic is upgraded in one contract, the data will persist in a separate, untouched contract. The previous contract will be manually shut down, and all web applications and users will be redirected to the address of the new contract. Via this process, the functionality of the protocol can be switched out without losing the previous data.

The next section is a breakdown of each individual contract, along with their functions. This section is primarily for anyone interested in the specifics of the contracts and is not intended for a non-technical audience.

QuantstampAudit

QuantstampAudit.sol in this first iteration stores a few different pieces of information in order to accomplish its goals:

• The price buckets available to auditors
• A queue of the requested audits within each price bucket
• A pointer to the QuantstampAuditData contract

The contract uses linked lists to hold onto and navigate this data. Upon receiving an audit submission from a Requestor, the Contract looks for a price bucket at the requested audit’s price. If the price bucket does not exist, it is created. The audit is then stored within the bucket at the end of its queue.

When an Audit Node seeks to perform an audit, the contract goes to the highest price bucket available. If the price bucket is above the minimum price the Audit Node is willing to accept, the contract removes the oldest audit in that price bucket from the linked list (essentially popping from the front of the price bucket’s queue) and assigns it to the Audit Node. Else, no audit is assigned. If no audits are left in the bucket’s queue after assignment, then the bucket is also removed from the price bucket list.

If the audit is not picked up for some period of time, the Requestor can call for a refund. Again, the audit will be removed from the price bucket’s queue, and the price bucket will also be removed from the list of buckets if no more audits remain within it.

Here’s a breakdown of the public functions currently within the logic contract:

requestAudit()

Inputs:

• URI pointing to the smart contract (string)
• Price to be offered in the event of a completed report (uint256)

Output:

• An ID pointing to the generated request of the Requestor (uint256)

Effects:

• Deduct the price from the Requestor’s account.
• Add the request to the audit data contract.

Conditions:

• Contract is not paused

getNextAuditRequest():

Inputs:

• None

Outputs:

• None

Effects:

• Check whether the oldest audit in the assigned audit list is expired. If so, it sets the state of that audit to Expired.
• If no failures, add the request to the audit data contract, including the auditor and timestamp.
• Increment the number of assigned requests for the auditor.

Conditions:

• Can only be called by whitelisted auditing nodes
• The node must not exceed its max cap for audits

submitReport()

Inputs

• ID of the request (uint256)
• State of the audit (enum)
• Hash of the report (string)

Outputs

• None

Effects:

• Update the state of the audit
• Transfer compensation to the auditing node as a reward

Conditions:

• Will only succeed if called by the Auditor of the request

refund()

Inputs:

• ID of the request (uint256)

Outputs:

• True if the token was transferred back to the Requestor, false otherwise (bool)

Effects:

• Remove the ID from the queue if already in the queue
• Set the state in the audit data contract to Refunded
• Send the price back to the Requestor

Conditions:

• Cannot succeed if audit has already been Assigned and the timestamp is not yet past expiration

resolveErrorReport()

Inputs:

• ID of the request (uint256)
• Recipient of compensation, true if Requestor and false if Auditor (bool)

Outputs:

• None

Effects:

• Transfer the price to either the Requestor or the Auditor, depending on Quantstamp’s decision
• Set the audit’s state to Resolved

Conditions:

• Can only be called by the owner, Quantstamp

QuantstampAuditData

QuantstampAuditData.sol can only be modified by QuantstampAudit.sol and the owner of the project, Quantstamp. Its logical functionality is limited to avoid constraining future forms of the logic contract, primarily filled with getters and setters, functions to retrieve and assign variable values

Within the contract is a custom data structure, or struct, called Audit containing all the relevant information about an audit, including the requestor, price, state, and timestamp. The contract stores the following pieces of data across all versions of the protocol:

• A mapping from data type uint256 to Audit to associate IDs with audits
• The address of the QSP token contract
• The timeout (in blocks) of audits
• The maximum number of requests any audit node can have assigned to itself at any given point in time
• The minimum price each audit node is willing to take for an audit
• The list of whitelisted audit nodes
• The most recent ID assigned to an audit

No matter the logic of the contracts in future iterations of the protocol, they will always use these pieces of information in some way.

Here’s a breakdown of the public functions:

addAuditRequest()

Inputs:

• Audit requestor (address)
• Contract URI (string)
• Price (uint256)

Outputs:

• ID of the request (uint256)

Effects:

• Request is stored at the given ID within the contract
• The request ID counter is incremented by 1

Conditions:

• Can only be called by the QuantstampAudit contract or by the contract owner

getAuditContractUri(), getAuditRequestorAuditPrice(), getAuditState(), getAuditRequestTimestamp(), getAuditAuditor(), getAuditAssignTimestamp():

Inputs:

• ID of request (uint256)

Outputs:

• Relevant value

Effects:

• None

Conditions:

• None

setAuditAuditor(), setAuditAssignTimestamp(), setAuditReportHash(), setAuditReportTimestamp():

Inputs:

• ID of request (uint256)
• Relevant data

Outputs:

• None

Effects:

• Sets relevant value to data passed as argument

Conditions:

• Can only be called by the QuantstampAudit contract or by the contract owner

setAuditTimeout()

Inputs:

• Timeout in blocks (uint256)

Outputs:

• None

Effects:

• Assign the new value to the timeout in blocks variable

Conditions:

• Can only be called by the contract owner, Quantstamp

setMaxAssignedRequests():

Inputs:

• Max assignments for any node (uint256)

Outputs:

• None

Effects:

• Assign the new value to the max requests variable

Conditions:

• Can only be called by the contract owner, Quantstamp

getMinAuditPrice()

Inputs:

• The auditor address (address)

Outputs:

• The auditor’s min price (uint256)

Effects:

• None

Conditions:

• None

setMinAuditPrice()

Inputs:

• Auditor address (address)
• The new min price (uint256)

Outputs:

• None

Effects:

• Set the auditor’s address min price to the new value

Conditions:

• Can only be called by the QuantstampAudit contract or by the contract owner
• isWhitelisted():

Inputs:

• Node address (address)

Outputs:

• True if whitelisted, false otherwise (bool)

Effects:

• None

Conditions:

• None

addNodeToWhitelist()

Inputs:

• Address to whitelist (address)

Outputs:

• True if successful, false otherwise (bool)

Effects:

• Add the given address to the list of whitelisted nodes

Conditions:

• Can only be called by the owner

removeNodeFromWhitelist()

Inputs:

• Address to remove from whitelist (address)

Outputs:

• True if successful, false otherwise (bool)

Effects:

• Remove the address from the whitelist

Conditions:

• Can only be called by the owner

getNextWhitelistedNode()

Inputs:

• Whitelisted address (address)

Outputs:

• Address next to input address in whitelist (address)

Effects:

• None

Conditions:

• The input address must be a whitelisted node, otherwise the call will fail

QuantstampAuditView

QuantstampAuditView.sol is meant primarily as a way to easily access data about the contract, therefore it stores little to no information itself. The only meaningful information it stores is the address of the QuantstampAudit contract so that any users or interfaces will know which contract to look to even in the event of an upgrade.

setQuantstampAudit()

Inputs:

• The new address of the Quantstamp Audit (address)

Outputs:

• None

Effects:

• The audit contract is updated to the new address

Conditions:

• Can only be called by the contract owner
• The address cannot be null

getMinAuditPriceSum()

Inputs:

• None

Outputs:

• The sum of all the minimum prices (uint256)

Effects:

• None

Conditions:

• None

getMinAuditPriceCount():

Inputs:

• None

Outputs:

• The number of minimum audit prices — should equal the number of whitelisted nodes, as there will be exactly one minimum audit price for each node (uint256)

Effects:

• None

Conditions:

• None

getMinAuditPriceMax()

Inputs:

• None

Outputs:

• The highest minimum price that a whitelisted node is willing to do an audit for (uint256)

Effects:

• None

Conditions:

• None

getMinAuditPriceMin()

Inputs:

• None

Outputs:

• The lowest minimum price that a whitelisted node is willing to do an audit for (uint256)

Effects:

• None

Conditions:

• None

Author:

Nadir Akhtar, UC Berkeley, Computer Science

Nadir supports the Quantstamp auditing team and has also served as President and Head of Education at Blockchain at Berkeley, a student-run organization which does education, consulting and research into blockchain. He is currently completing his Bachelor’s in Computer Science at UC Berkeley.

© 2018 Quantstamp, Inc. All rights reserved. This content shall not be used, copied, modified, redistributed or otherwise disseminated except to the extent expressly permitted by Quantstamp.

Notice: This information may include non-functional, illustrative descriptions or concepts provided for demonstration purposes only and detailed implementation is subject to continuing development, changes, or cancellation in Quantstamp’s sole discretion. This content is provided for your personal, non-commercial use for informational purposes only and should not be relied upon for tax, financial, legal, regulatory, or other advice. Use of Quantstamp materials is subject to participation terms.

Like this content? Subscribe to our newsletter at Quantstamp.com or follow our Twitter, Facebook, or Telegram channel to stay up to date with Quantstamp.

Securing Smart Contracts on the Blockchain: A Technical Overview of the Quantstamp Betanet Protocol was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

It appears to be a game where someone, presumably the contract owner, asks a question. If a player guesses the correct answer, they receive the contract’s balance as a reward. When I found the contract, it was holding a balance of approximately 1.03 Ether. Fishy, right?

By analyzing the code, we can immediately spot a few odd things. My first impression was that this contract must have been implemented by a beginner developer who is just getting into the Solidity and Ethereum space. However, after proper investigation, it turned out to be a carefully composed piece of code that only pretends to be naive. Let us have a look at everything that is going on here.

The contract uses Solidity compiler of version 0.4.20 and above. Given that 0.4.25 just came out, it appears to be a bit old. Furthermore, it declares the version as “at least” (using the ^ character). This construct is valid for implementing interfaces and library contracts that are reused in other projects, but smart contracts deployed to the blockchain should fix a single version of solidity that they were implemented in and tested against. This is merely important for projects with ongoing development and does not pose any security threat to us.

The contract declares three internal attributes that represent its state: a question (string, line 16), the hash of the answer to this question (byte32, line 20), and the address of the person who asked the question (address, line 18). This is all that the contract needs to carry out its function, which is to decide whether a player provided the correct answer, and if this is the case, to transfer the balance to them. Rather oddly, the contract does not implement the constructor method where these attributes would be initiated. Thus, when deployed, all the attributes receive the default values. The contract further offers additional methods that allow the owner to set the question. Such a solution requires the owner of the contract to run multiple transactions and spend more gas. Again, this appears to be a beginner’s mistake, but in fact, it is a deliberate construct.

After deploying the contract, the owner is likely expecting to call method StartGame (line 22). This method sets a question, response hash, and also persists the address of the person who asked the question. However, all of these actions happen only if no response hash exists yet, otherwise the method has no effect. This is taken care of by wrapping the code inside of an if statement.

In addition to StartGame, the contract also provides a function NewQuestion (line 42). This function assumes that some question was asked before as it requires that msg.sender is the person who asked the current question. If that is the case, it overwrites the question and bytes of the hash. This method can be called repeatedly by the person who asked the question. This exposes the players to a “transaction ordering vulnerability” as follows. Assume that a question has been asked by the contract owner. Any player who sends a transaction with an answer would be waiting for the miners to record it in the blockchain. If the question poser changes the question at the same time by invoking NewQuestion method, and if this transaction is mined first, the player’s answer will be answering the wrong question. This method can be called repeatedly, regardless of the state of the contract.

Furthermore, the contract offers a method for playing. It accepts an answer and requires some Ether to be sent along with it. Interestingly, the method first checks that msg.sender == tx.origin. The best practices of Solidity warn against the use of tx.origin in order to verify that methods are called by certain users (most frequently the contract owner). However, this is a different and valid use. This construct ensures that there is no middle man in this method invocation, i.e., that the method was called directly by the player’s wallet and not through another contract. Then, if the hash of the provided answer is the same as the hash of the question asked, and if at least 1 Ether was sent along with it, the contract will pay out its balance to the successful player. Otherwise, the Ether sent along will be kept by this contract and will become a part of the reward.

The contract allows the question poser to stop the game and retrieve all the Ether by calling function StopGame (line 34). This is another exposure to the transaction ordering vulnerability. If a player sends an answer with some Ether, and if the question poser decides to stop the game while the player’s transaction is waiting, the player will lose either gas if the provided answer is correct (the player will win and receive the Ether sent along less gas), or all the Ether if the answer is wrong. This method can also be called repeatedly regardless the state of the contract.

Finally, it also implements an empty fallback (line 51).

So, let us summarize. We have some transaction ordering dependence that exposes us to some potential manipulation. Furthermore, the contract has some odd-looking and inefficient constructs. Most importantly, it seems to assume that the data in private attributes are hidden from the world. Beginner’s mistake — -we can look at the transaction history, we can precisely decipher what the answer is. With the balance of this contract being a bit over 1 Ether, participating in this game seemed like an appealing opportunity for any potential player.

At this point, I was convinced that this contract was a scam. I was convinced that something beyond my understanding would cause players to lose their Ether. I decided to see if I could learn more about how this scam worked. I used Etherscan to look at all of the transactions, which included a single internal transaction. I saw the screen below that told me that the owner performed exactly 2 actions:

1. Created the contract in block 5873826 via transaction 0xf9f25d11…85c6
2. Asked question “Imagine you are swimming in the sea and a bunch of hungry sharks surround you. How do you get out alive?” with the answer “Stop Imagining” and added 1.030103834778 Ether as the reward in block 5873943 via transaction 0x41365b3d…fa5b

No internal transactions were recorded. So, I transferred some Ether to my Metamask account and went ahead. I first answered the question with no Ether attached. I wanted to create a transaction with the proper answer to doublecheck that it will be encoded exactly that same as when the owner created it. If that is the case, SHA256 should produce the same result. I used MyEtherWallet and Metamask to call the method. An inspection of the created transactions told me my assumption was correct. That was all I needed. I sent in 1.05 Ether (strictly more than 1 in order to satisfy the condition), and the answer. When my transaction got mined, the expected happened! The balance of the contract increased to a bit over 2.08 Ether, and my wallet remained nearly empty.

Clearly, I must have missed something. I kept inspecting the code and the transaction and could not wrap my head around it. The transaction ordering was correct. I could not see anything else in the code, so I deployed it locally and verified the behaviour through tests. Everything behaved exactly as expected. While I was investigating, the balance of the contract dropped to 0 as the question poser stopped the game roughly an hour after my response. And this transaction revealed everything.

The contract did not transfer the balance (including my Ether) to a wallet, but to another contract with private source code. When investigating the history of transactions, I found out that there is one internal transaction going to the game contract, and that this transaction does not show up in the history of the game contract’s transactions on Etherscan! The real sequence of actions was as follows:

1. The creator deployed the middle-man contract in block 5806406.
2. The creator deployed the game contract in block 5873826.
3. The creator sent a transaction to the middle-man contract in block 5873890 that made two calls to the game contract. Both these calls are invisible in the transaction history (both internal and external) of the game contract on Etherscan, but they can be found in the traces of the transaction. The calls and parameters can be decoded using the game contract’s ABI that is available on Etherscan and any Ethereum input decoder, for example the one here. The first action calls StartGame with “Imagine you are swimming in the sea and a bunch of hungry sharks surround you. How do you get out alive?” as the question setting the right answer to “sZs”. The other action calls NewQuestion with the same question and sets the hash to some bytes (see Figure 5).
4. The creator sent a direct transaction in block 5873943 to the game contract’s StartGame with the question “Imagine you are swimming in the sea and a bunch of hungry sharks surround you. How do you get out alive?” and answer “Stop Imagining”. This transaction had no effect on the state of the contract. The answer hash was no longer 0x0, but this hash was very visible on Etherscan.
5. I came and played with the wrong answer.

Let us now step back and admire the elaborate construction of this contract that targets the users of Etherscan and similar Ethereum explorers exploiting the fact that Etherscan does not show incoming transactions invoked by external contracts. First, let us look at how StartGame checks that no response exists yet. It wraps the body in an if statement, which plays the role of a silent invisible killer. There are some code alternatives that would achieve the same effect, most prominently using require(responseHash == 0x0). However, the if statement used on line 26 does not cause a throw, so the fact that the state of the contract did not change will not be indicated to the audience by failed transactions.

Second, method NewQuestion on line 42 accepts the answer hash, that is, a sequence of bytes. At the same time, playing the game (line 5) asks for the original answer in the form of a string, and StopGame on line 34 does not require the question poser to prove that the answer is known at all. As a result, if we somehow discover that this internal call happened, we are still unable to guess the answer. The blockchain will tell us what its hash is, but from the principle of irreversible hash functions such as SHA256, it does not tell us anything about the input. While we could theoretically start searching for the proper answer using brute force, the search space is infinite. In fact, I am not even aware of a proof that the answer exists! Since StopGame does not require the question poser to reveal the answer, I suggest that even the person who set this contract up does not know what it is, and in fact, the provided sequence are just some random bytes.

Lastly, independently of this issue, the developer made all the effort to skew the system to his own benefit. Remember line 9 in Play method that guaranteed that this method cannot be called via another contract, and the transaction ordering vulnerabilities? As a careful player, I would be able to go around the transaction ordering by invoking Play via another contract. This contract would first check that the question and balance did not change; i.e., nobody called StopGame or NewQuestion with a different question, and nobody beat me to the answer that I wanted to guess, and only in such a case, make a call. Yet, this is not possible, because the invocation must come from a wallet.

So, what is the message here? Mainly, Etherscan does not reveal everything. There are people out there who know it and exploit it! There are other Ethereum explorers that do not seem to suffer from this issue (I was able to find all the transactions here for example), but there is no guarantee that they do not suffer from different vulnerabilities.

This type of scam targets the imperfections of blockchain explorer UIs. In order to counter it, companies operating blockchain explorers should become aware of these vulnerabilities so that they can modify their UI in order to prevent clever scammers from exploiting their users.

Luckily, as a user you do not need to rely on an explorer to read the blockchain. If you want to reliably know what happened on the blockchain, read the chain directly!

Here are more contracts that I discovered that take advantage of the same vulnerability.

This contract is still alive: https://etherscan.io/address/0xce6B1AFf0fE66da643D7A9A64d4747293628D667#code

Game stopped, but Ether was stolen: https://etherscan.io/address/0xFf45211eBdfc7EBCC458E584bcEc4EAC19d6A624#code

Game stopped: https://etherscan.io/address/0x4bc53ead2ae82e0c723ee8e3d7bacfb1fafea1ce#code

Game stopped: https://etherscan.io/address/0x3B048ab84ddd61C2FfE89EDe66D68ef27661C0f2

Game stopped: https://etherscan.io/address/0x5ccfcDC1c88134993F48a898AE8E9E35853B2068#code

Exploiting the interface of Etherscan for Ethereum attacks was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Proof of Authority network is a new advancement in blockchain research created by the Parity team and coined by Gavin Wood. A big PR was created in August 2017 to merge PoA code into the Parity application. This code has since been merged and as of the build on my machine (Parity/v1.10.2-unstable-f4ae813fd-20180423/x86_64-macos/rustc1.24.1) the tutorial progressed nicely.

First impressions reminds me of previous work I’ve done with distributed computing infrastructure. Clustered database and compute platforms like Erlang OTP, CouchDB and Riak have a similar bootstrapping procedure. Cloud Native platforms like Kubernetes have a distributed key/value database called etcd that also reminds me of Proof of Authority.

The gist of the tutorial goes like this

1. Create a chain specification using the AuthorityRound engine
2. Create three accounts, one for the “authority” on each node and a single “user” for testing transactions
3. Update the chain specification to include the two addresses as validators for the AuthorityRound engine and a single blessed user with lots of fake ETH monies to spend
4. Include passwords (shared secrets) to unlock the validator accounts as a configuration file. Opinions on this later…
5. Configure the validators as each other’s miners using the engine_signer keyword with the address of the other node’s validator account, specified in the chain spec
6. Obtain the enode identifier URL for node0 and pass it to node1 as an association. In other words, inform the nodes about each other
7. Do transactions as the user account on node0

Seven steps. Not bad for a distributed computing tutorial. Excluding the time spent compiling the Parity client from source, it took me about two hours to get this demo running while writing a few scripts to automate some of the copy + paste steps and begin the draft of this essay.

I’ve published my work at https://github.com/lazzarello/proof-of-authority-tutorial

So what makes this system different to the other distributed computing applications I’ve cited above?

A “multi-master” environment emerges from the nodes following the manual bootstrapping process. The short time where the validators are bootstrapped is the only point where the network is in a state where there are “master” nodes which have more privileges than other nodes. Once they are configured to be validators they have the privilege of putting blocks into a pool but they also contain all the features as any other node in the network. All RPC functions are available from all nodes and state will converge the same way as on any other Ethereum network.

Transactions can originate from any node and will find the path towards validation without any user intervention beyond what is expected from an Ethereum node. This messes up the “multi-master” model in my brain a little since transactions can be sent to any node, even one that isn’t a master. It’s like there is a thin multi-master distributed database as an overlay to the whole cluster that works to validate transactions.

This model is very compelling to me. It’s hands down the fastest bootstrapping process to get up and running to do smart contract dev, understand infrastructure and build Ðaaps. There is an open source project to provide a PoA network and utilities like a block explorer. There’s also protocols in development to migrate from an existing PoA chain to a different chain with a different transaction validation model, for example the Proof of Work model in the Foundation mainnet as of this writing.

On shared secrets

Bootstrapping nodes with a shared secret (aka a password) is quick for a tutorial where the reader is present to do copy and paste operations into a config file. For a decentralized network, this security model might not scale. Passing around and storing shared secrets presents a risk.

Since we are using Proof of Authority for our validators, we can borrow concepts from traditional distributed computing patterns. Part of the validation process could include a public key exchange and a signed certificate issued by the validation authority. This is a manual exchange which would require explicit trust between the validation authority and the potential new validator node.

An example from the Web 2.0 years is the Chef cloud automation platform. It uses a public key infrastructure (PKI) with validator certificates to bootstrap new nodes in a cluster. There is also an option to explicitly trust a user certificate and validate new nodes using that trust relationship. While this pattern has been adapted to the world of containers in platforms like Kubernetes, the PKI remains.

Running a node

It’s worth noting that Parity sponsors (built?) a new PoA test network called Kovan with some faucets to get ETH and try things out. As of this writing I don’t know the process to prove one’s authority and become a validator node on Kovan. Running Parity locally on Kovan is as simple as parity --chain kovan. Also as of this writing, the sync time is about 30 minutes to obtain data from 233 snapshots.

About 7 million verified blocks were synced to my node in 30 minutes. New blocks and transactions began flowing in immediately. This is a vast improvement over the > 2 weeks (~ 20160 minutes) required for a full archive of the PoW Foundation mainnet.

I’m excited to experiment more with Proof of Authority networks. I’ll be writing more during this process.

Building a Proof of Authority network with Parity was originally published in quantstamp on Medium, where people are continuing the conversation by highlighting and responding to this story.