Introducing the Quantstamp Security Assurance Protocol
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:
- 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;
- 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;
- Assurance providers, by conducting more security research, may choose to increase the stake by leveraging premiums to further assert their confidence in various projects;
- 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.
