A Path to Chia Hardware Wallet Support
Chia goes hard(ware): Ledger, Trezor, and other hardware wallets coming soon to a green blockchain near you
I managed to sign Chia transactions with my Ledger, Trezor, and Tangem cards yesterday. Here’s how.
Chia community members have been asking for Ledger support for quite some time. That being said, making a Ledger app is not easy. From what I’ve heard, the coding part is difficult just by itself. There’s limited space - Ledger Nano X has 2 MB of storage, which is advertised as being sufficient for ‘up to 100 apps’ - and very limited computing power. Within these constraints, building an application that can parse Chia transactions might not even be possible - and we haven’t even considered issues such as application verification requirements, limited screen size, and possible delays in getting support for new primitives.
If developing a Ledger app is so difficult, why not find an alternative path? To understand how that’s possible, we first need to take a step back and talk about a popular Ethereum standard.
EIP-712
When people say “signing” in crypto, they usually refer to signing transactions. But the cryptographic primitives powering blockchains mostly allow signing *any* data. At some point, some websites/dApps started asking users to sign messages off-chain - the signatures would either be used for logins (i.e., proving the user owns an address) or later submitted on-chain to custom contracts.
There was, however, one big problem: users didn’t know what they were signing. They only saw a final hash - with no way to tell if they were signing into a website or approving a malicious actor to drain all their funds on another dApp. The signing requests looked like this:
The EIP-712 standard was proposed to solve this problem by specifying a way to convert structured data into a hash to sign. Websites could then pass the structured data to wallets, which parse it and display a much nicer request to the user:
Most wallets currently support the EIP-712 standard (including hardware ones), which made it an interesting avenue to explore. A Chia wallet could just prompt users to sign a message to ‘prove’ they want to spend a coin in a specific way. Indeed, the demo puzzle I used last Friday verifies the signature of such a message on-chain. Here’s how the signing request looked like in my Tangem app:
The puzzle was made to act as a replacement for the standard puzzle - meaning that hardware wallets should be able to hold CATs, NFTs, DIDs, and any other primitives we invent. Because EIP-712 is so widely supported, this approach allows integrating Chia with pretty much all wallets that support Ethereum and EIP-712.
CHIPs
There was one critical barrier in adopting EIP-712 for Chia: Ethereum uses keccak256 for hashing EIP-712 data, while Chia relies on sha256. The keccak256 operator isn’t currently available in chialisp.
Thankfully, there is a process through wich new operators can be added: CHia Improvement Proposals (CHIPs). Community members can propose standards or operational changes, which undergo a feedback phase. Some proposals end up being withdrawn (such as the one proposing a minimum transaction fee), while others pass (such as the one defining an upgrade to the datalayer standard).
After my request, the keccak256 operator now has an associated CHIP that will eventually add it to chialisp.
What’s Next
Now that we have a clear use case, the keccak256 CHIP will proceed at full speed. Since it’s a new operator, a ‘soft fork’ will be needed, meaning nodes will need to be updated to support keccak256. In practice, this involves a transition period - typically 2-3 months - before the operator is enabled, giving farmers and other node operators time to upgrade their software.
While the CHIP process is in motion (follow it here), there’s more groundwork to lay for hardware wallet integration. Rigidity has been working hard on an impressive Chia SDK I’ve had the pleasure of using many times (including in this project), as well as a new wallet called Sage, which plans to support the new puzzle. This is a complex undertaking, so if you’d like to help, consider supporting Sage development, either by donating here or by spreading the word about Sage (available in beta here).
Special Thanks
Julie for first suggesting using EIP-712 in this thread with me. The previous solution involved signing ‘fake’ Ethereum transactions and was much more convoluted.
CNI for going through with my CHIP request even tho it wasn’t clear if the idea would work or how it would work (the latter being a communication problem on my side).
Rigidity and Indigo for quickly getting keccak256 PRs set up, thus enabling the development environment I needed. Also for going through the softfork operator with me.