cip-0049.md

cip	title	status	type	discussions-to	author	created	license
0049	Transaction Signature Safety	Abandoned	Informational	#293	Nam Chu Hoai (@nambrot)	2021-10-12	Apache 2.0

Abstract

This CIP outlines a roadmap for a collection of improvements aimed at making transaction signing more transparent and by extension hopefully safer for users, especially less technical ones. The proposed measures for the most part are fairly chain-agnostic (i.e. not specific to Celo) and could be ported over to other chains easily.

Motivation

One of the key characteristics of decentralized networks that have come since the Bitcoin whitepaper is the use of non-custodial cryptographic keys to authenticate user intent. Instead of a user telling a bank to initiate a transfer which makes them and their underlying infrastructure a gatekeeper, anyone is able to sign a transaction and submit it to the network (assuming it is credibly decentralized and neutral). With the creation of Ethereum, smart contract platforms have expanded to general purpose computation. However, as the complexity of transactions that can be signed has increased, the ability for users to understand the implications of what their keys are signing has not. Often, the only information available to the users are the to contract as well as the raw data bytes. As this space moves away from early adopters to "the mainstream", we can no longer rely on informed users who have build muscle memory for protective heurestics.

Specification

The roadmap is proposed as follows:

1. Make contract verification and transaction decoding accessible to developers

The current state of contract verification is mostly manual in its consumption from hosted block explorers, some of which are proprietary and permissioned. We propose to leverage Sourcify.dev to facilitate access to verified source code and ABIs. This includes both tooling/documentation to make verifying on Sourcify easier, as well as fetching from it. It may even involve verifying popular contracts by recompiling. Following/extracting from CeloTerminal would be the most likely avenue for this. This tooling can be written generally enough to ultimately fetch from other sources (Etherscan comes to mind.) As Celo Core contracts make significant use of proxies, support for them should be considered required for v1.

2. Demo via a WalletConnect Proxy

Since existence of tooling and documentation does not guarantee actual implementation for users, we propose to build a WalletConnect proxy as a demonstration of the "state of the art" experience. On the proxy, users can connect their wallet via use-contractkit(Celo)/Onboard.js(Ethereum) and then the proxy itself can be connected to the dapp. Requests for transaction signature can be displayed on the proxy first for introspection before forwarded to the actual wallet for signature.

3. Expand the experience

Up to this point, the experience is not actually state-of-the-art yet as some wallets do support selective transaction decoding. To improve upon the experience, it is necessary to provide judgement (read more why under Rationale). To quickly iterate upon which judgements (aka attestations) are actually valuable, we propose to use the proxy for that experimentation which effectively makes the hoster of it a trust-delegated party. The entity is encouraged to use an open-source repository of these attestations on Github to leave an audit trail and allow for discussion. When the value is validated, these attestations can be exposed via an API and further decentralized via Step 4.

The most impactful attestations we propose are:

• Canonical Identity Attestation
  • Example: { type: 'canonical_identity', project: 'Ubeswap', contract: 'Ubeswap Router' }
  • Knowing which contract we are interacting with is the most powerful defense, one that many current users do by going on a block explorer and verifying there. It leverages the reputation of the project and the rough consensus of legitimacy to assure the user.
• Warning Attestation (aka the rug pull attestation)
  • Example: { type: 'warning' }
  • When a contract is known to be a rug pull, there are currently few avenues by which users can be warned to cease further interaction with
• Contract Interaction Stats
  • Volume Attestation
    • Example: { type: 'volumeStat', volumeLast24Hours: '1M', volumeLast7Days: '10M' }
    • The more value has interacted with this contract, the
    • Issues:
      • Has to be dynamically computed with an indexer
      • can be gamed via wash trading
  • Balance Attestation
    • Example: { type: 'balanceStat', value: '100M' }
    • The value this contract holds is in effect an attestation by the holders of the value
    • Issues:
      • Contract can be permissioned for the owner to rug

4. Decentralize and turn into a protocol

When the value of this approach is validated, the final part of this proposal is to turn it into an actual protocol by creating a "market" for these attestations that anyone can make and can subscribe to. For this, an established identity protocol is required, as well as a means of publishing and consuming these attestations.

Rationale

The philosophy behind this proposal is to help users navigate the risks of signing data and decrease the semantic gap. Wallets as the technical custodians of key are believed to be the primary responsible party to surface relevant data to the user in an accessible/understandable manner. Building tooling to lower the cost for wallets acting upon that responsibility is a positive externality for the whole ecosystem. However, neutral verification is limited and ultimately judgements of various kinds have to be made. We shall call them attestations and below follows a treatment of relevant considerations/dimensions:

What can be attested?

Attestations exist on a spectrum, from a loose "I believe this contract was deployed with good intent by good people" to a stricter "I did a thorough audit of this contract". While attestations of the latter end of the spectrum are of course the strongest, the number of entities that will be comfortable making those attestations is likely very small if non-existent. The scope of attestation as in the literal expression of the attestation might be different from user interpretation. Even if someone like cLabs just attests "We superficially looked into the project and think it's probably fine", it's unclear to me whether there is moral or legal liability in case of loss of funds. In that light, keeping the set of possible attestations small to set the right user expectations is critical.

Another relevant dimension of attestations are their domains, i.e. the underlying contract might be a valid one (i.e. the audited Multisig), but the wrong identity (i.e. a multisig controlled by an attacker vs. the governance approver multisig). Another example would be a token contract that pretends to be another legitimate one, and dupes you into providing liquidity for it.

With that being said, to prevent the most egregious instances of rug-pulls or phishing attacks, we propose the following set of attestations to consider:

• Code Intent: The ABI for this contract is indicative of the code's intent
• Canonical Identity: The identity of this contract is X.
  • I.e. this is the UBE token contract
• Good Faith Identity: This identity is a good faith actor.
• Rug-pull: Something is wrong with this contract/identity, please use caution
• (Maybe) This contract was audited by X (X does not have to be the attester)
• (Maybe) Owner of this contract can significantly impact functionality of this contract (with ideally some kind of display of who the owner is)

Another class of attestations are quantitative in nature:

• Age of contract deployment
• Transaction count over 24 hours, 7 days, 30 days, 1 year
• Value that has interacted with this contract historically
• Value that is currently controlled by this contract (+ historically)
• Amount of LockedCelo this account represents (or any other illiquid asset indicating investment)

These numbers can theoretically be calculated independently, but practically require an indexer which in of itself is an attestation to running it correctly. Since some of these numbers can be gamed, an additional extension of these attestations is to calculate them relative to a users social graph, i.e. what number of my friends have used this contract.

Who provides attestations?

Attestations only provide value insofar that the consumer of the attestation values the judgement of the attester. That could be the following parties:

• The developer itself (i.e. the contract deployer or the contract itself)
  • While maybe one of the weaker attesters, it would still protect against supply-chain attacks within the developer. I.e. if the key that identifies the developer is "colder" than access to the frontend code itself, it will lower the success rate of an attack. (similar to DNS record control)
• The Wallet developer
  • A user's wallet developer is likely their most important trust relationship, thus it makes sense to leverage that relationship to provide these attestations. However, it is unclear whether wallet developers will want to provide these attestations and instead delegate them to other parties with domain knowledge.
  • An interesting example of this is Argent's trust list (https://support.argent.xyz/hc/en-us/articles/360019125917-Transactions-with-Trust-Lists), though their attestations are very binary
• cLabs/ecosystem developer
  • As the most identifiable steward of the Celo platform overall, cLabs already is taking plenty of responsibility for the safety of users and thus is in a natural place to provide these attestations. While cLabs likely won't conduct actual audits, lightweight attestations seem possible and are the recommended first step.
• Celo foundation
  • Similar to cLabs.
• Trusted community members/crowdsourced/service providers
  • Assuming that the identity attestation from 2.1 is implemented, everything would be in place for a market/community of attesters to develop that users can subscribe to. It is also worth noting that developers of project A integrating with project B will have an incentive to provide an attestation for project B. (i.e. Moola + Ubeswap)

How to identify an attester?

While specifying the identity protocol this proposal would use is out of scope, it is worth noting which identity attributes are relevant for it. While entities such as cLabs or the foundation can probably publish their addresses easily, it becomes marginally more difficult for projects building on Celo. Currently, the strongest attributes users associate with projects are their websites (i.e. domain name) and their twitter accounts, which would also be the proposed requirements for the identity protocol from this proposal.

How to communicate an attestation?

This is a minor point but and again slightly outside the scope of this proposal, but given the relative high cost of providing attestations, all measures should be token to make the conceptual and practical overhead of doing so minimal. In this context, both the signing and storage/publication of the attestation should be doable with already accessible tooling. For signing, EIP-712 seems the most accessible. For storage, a centralized approach could work but is not ideal to generalize further. CIP-8 with additional work like a centralized hosted version could get the same accessibility while providing the path for decentralization.

Security Considerations

While of course the goal of this proposal is to increase transparency and safety for users, it shall be noted that this proposal does increase the surface area of code, services and entities that are being trusted which could open more opportunities for phishing. It's important for the community but especially implementors to understand how to display the information to users so that phishing users doesn't become trivial.