Storing your Ethereum Safely
Today, we’re excited to announce Ethereum support on Casa! However, there is one catch…
Casa will only support single key management of Ethereum.
Current Ethereum multisig is fundamentally insecure, and we refuse to risk client funds and our reputation on current options.
The good news is that there are several potential solutions:
1. Establish & formally verify a standard multisig contract.
2. Implement account abstraction.
3. Custom native multisig.
Today, we are making a constructive recommendation to the Ethereum community on path forward with a goal to resolve this fully at DevCon 4 in October.
Why does Ethereum need better value storage?
Casa is designed for long-term, safe and secure value storage. We started with Bitcoin because it was designed to be a kind of digital gold, and is the hardest value storage in the world.
Ethereum is different — designed to be a computation platform — but that doesn’t mean that storing value can be ignored. In fact, storing value and correctly linking ownership of that value is the single most important feature of Ethereum. “Value” includes not only ether, but utility tokens, security tokens, unique/non-fungible tokens, etc. Nobody is going to use Ethereum to prove their identity if that proof can lost accidentally or wiped away in seconds due to a bug.
The Parity hack and loss of funds last year factored heavily into our decision to avoid existing Ethereum multisig. It demonstrated that in some cases, even if the logic of a smart contract is sound, there are attack vectors that can be accidentally or intentionally triggered where loss of funds is enormous.
There is another, less obvious danger for the Ethereum community aside from loss of funds. If users of Ethereum aren’t confident in their ability to securely and easily store value, then many users will simply move to other platforms.
How do we improve Ethereum value storage?
With most Ethereum wallets today, only a single signature secures funds. It takes just one password hack or stolen device to steal funds. There are no user friendly, secure multisig wallets available on Ethereum mainnet (Gnosis’ Safe app is the closest, but still in testing on Rinkeby testnet).
We firmly believe that while single signature wallets will continue to exist, the majority of value will eventually be stored in multisig wallets due to the huge improvements in security they provide.
The Casa team proposes three distinct options to improve Ethereum fund security:
- Create or designate a standard multisig smart contract. (Fastest option)
- Finish building account abstraction, which allows any type of signature scheme when sending transactions. (6+ months dev time minimum)
- Add multisig at the EVM level, with no reliance on smart contracts or account abstraction. (6+ months dev time minimum)
Option 1: A Smart Contract Standard
A standardized smart contract is the fastest & simplest way to accomplish safer multisig on Ethereum.
There are many different multisig contract implementations that exist today in Ethereum, but none have been solidified (😉) as a standard for the community.
Why is a standard so important?
Because successfully creating a Standards Track EIP (of the ERC variety) brings intense scrutiny and focus from Ethereum protocol developers and the community at large, which will help ensure that such a fundamental building block for the ecosystem is properly vetted for safety.
In addition to the normal EIP process, formally verifying the contract would significantly improve our confidence in its security.
Finally — and most importantly — if a logical or technical flaw were to ever be found in the community standard multisig smart contract (OR worse, if a 0-day were discovered at the EVM or even chip level that opened an attack vector on a logically sound contract), we are confident that the Ethereum community would take steps necessary to fix the problem and recover funds. The Parity hack is a clear precedent of unexpected fund loss resulting from a non-standard smart contract.
There are a few existing multisig contracts we believe could be candidates for an ERC standard, or we could work to create a new contract (ideally with a focus on maximum simplicity to reduce potential bugs and attack vectors).
Existing contracts that we like, but that would require further vetting, are Gnosis’ Safe contract and Christian Lundkvist’s Simple Multisig contract. We are extremely grateful for their excellent work, and we want to help leverage their contributions to reach a standardized contract.
Option 2: Account Abstraction
Account abstraction is a protocol change that has been in discussion since at least 2015. The EIP was officially added in early 2017 by Vitalik, and it was originally planned for release in the Metropolis hard fork (September 2017). However, it was pulled out for two main reasons: the core team didn’t feel that enough effort had been put into testing the change, and it fit well with a sharding implementation, which will be released at a later date.
At a high level, account abstraction is a way to decouple the on-chain representation of an account from the signature scheme required to send a transaction for that account. Currently, the EVM validates a single signature type for every transaction. The account abstraction proposal allows for many signature types by shifting verification responsibility from the EVM to individual contracts. The signing process is handled off chain, and a signed message is passed to a validating contract on chain. After successfully validating the signature, the contract would forward the transaction on to the network.
Account abstraction would be a great solution to the multisig problem, but it will likely require more work and attention than implementing a smart contract standard. If there is general agreement in pursuing account abstraction, then its development should be decoupled from other major Ethereum features such as sharding. The sharding and proof of stake features are extremely difficult to develop and can easily be delayed (we don’t envy the Ethereum researchers working on those projects 😅). As I mentioned at the beginning of this post, account security is fundamental to the success of Ethereum and should be improved as quickly as possible.
Option 3. EVM level multisig
Our third proposed option involves creating a native form of multisig, which would be validated at the EVM level. This would use a signature aggregation scheme such as Schnorr or BLS, which would enable multisig, increase privacy, and decrease blockchain bloat.
This option is similar to account abstraction in that it still requires core protocol changes and a hardfork. However, it may be easier to safely implement since it minimizes the variety of signature schemes being validated.
Casa Recommends Option 1
We believe that Option 1 — creating an ERC standard smart contract — is the best path to take right now due to its balance of speed with relative safety.
We’ve begun work on a standards proposal with the goal of presenting it at Devcon 4 in October.
Please join this cause and contribute. The end goal is to make it safer for everyone to use Ethereum, and we realize we cannot accomplish this alone. We are already in conversations with other leaders in the space, including Gnosis, ConsenSys, and Grid+.
Thank you for reading and considering this recommendation. We’re excited to quickly build and ship a safer multisig for the Ethereum community.
What is Casa?
Casa is the best personal key system on the planet. Keep full control of your Bitcoin and Ethereum with multi-signature + multi-location + multi-device software combined with premium 24/7 support.
Appendix — Useful References
Existing Contracts Referenced
safe-contracts - Gnosis Safe allows secure management of blockchain assets.github.com
simple-multisig - Simple multisig for Ethereum using detached signaturesgithub.com
Formal Verification Process
Brian Marick and Daejun Park Runtime Verification Inc provides Formal Smart Contract Verification services. In this…runtimeverification.com
Brian Marick and Daejun Park Runtime Verification Inc provides Formal Smart Contract Verification services. The…runtimeverification.com
Special thanks to Gavin Wood for prompting my interest into abstraction improvements, and Martin Becze, Vlad Zamfir and…blog.ethereum.org
At the time of writing this, there are two types of accounts in Ethereum. First, there are external accounts which are…ethereum.stackexchange.com
The following is a copy of the account abstraction proposal discussed here but coalesced into one piece and adapted for…github.com
The goal of "account abstraction", as conceived by EIP 86 and other proposals, is to reduce the number of account types…ethresear.ch