Tracking issue: account abstraction in Conflux

[ChenxingLi]

Motivations

Ethereum's community is discussing the account abstraction, which enables the users to

create 'account contracts' that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.

They also provides several cases which can benefit from this feature in EIP-86

• Multisig wallets: currently, sending from a multisig wallet requires each operation to be ratified by the participants, and each ratification is a transaction. This could be simplified by having one ratification transaction include signatures from the other participants, but even still it introduces complexity because the participants' accounts all need to be stocked up with ETH. With this EIP, it will be possible to just have the contract store the ETH, send a transaction containing all signatures to the contract directly, and the contract can pay the fees.
• Ring signature mixers: the way that ring signature mixers work is that N individuals send 1 coin into a contract, and then use a linkable ring signature to withdraw 1 coin later on. The linkable ring signature ensures that the withdrawal transaction cannot be linked to the deposit, but if someone attempts to withdraw twice then those two signatures can be linked and the second one prevented. However, currently there is a privacy risk: to withdraw, you need to have coins to pay for gas, and if these coins are not properly mixed then you risk compromising your privacy. With this EIP, you can pay for gas straight our of your withdrawn coins.
• Custom cryptography: users can upgrade to ed25519 signatures, Lamport hash ladder signatures or whatever other scheme they want on their own terms; they do not need to stick with ECDSA.
• Non-cryptographic modifications: users can require transactions to have expiry times (this being standard would allow old empty/dust accounts to be flushed from the state securely), use k-parallelizable nonces (a scheme that allows transactions to be confirmed slightly out-of-order, reducing inter-transaction dependence), or make other modifications.

and in EIP-2938.

1. Smart contract wallets that use signature verification other than ECDSA (eg. Schnorr, BLS, post-quantum...)
2. Smart contract wallets that include features such as multisig verification or social recovery, reducing the highly prevalent risk of funds being lost or stolen
3. Privacy-preserving systems like tornado.cash
4. Attempts to improve gas efficiency of DeFi protocols by preventing transactions that don't satisfy high-level conditions (eg. existence of a matching order) from being included on chain
5. Users being able to pay for transaction fees in a token other than ETH (eg. by converting that token into the ETH needed for fees inside the transaction in real-time)

Besides that, there is another important case for Conflux

• Sign Conflux transactions by Metamask: If a message signed by Metamask can be accepted as a valid transaction on the mainnet of Conflux, the user can do almost everything on Conflux without installing. This can reduce the barrier to experience Conflux.

Why Conflux can have a better solution than Ethereum?

In EIP-2938, Ethereum community provides a complicated solution to implement account abstraction, which includes two addtional opcode and the gas price/gas limit can be changed during transaction execution. This makes the transaction packing logic much more complicated.

Fortunately, Conflux has sponsorship mechanism, which enables a more elegant solution for account abstraction. Even without any upgrade, Conflux can still support some use cases in account abstraction.

For example, consider the cUSDT token contract want to support account controlled by ed25519 public keys. The contract developer can implement a function called submitEd25519TransactionWithSign(address sender, address receiver, uint value, bytes signature) and sponsor for all the addresses. A user can use a normal Conflux address to call this function and submit ed25519 signature. Benefit from the sponsorship mechanism, it is not necessary that the sender has CFX tokens. So the sender can generate a random string as private key, sign the transaction and send it.

What to do next?

This example still has several drawbacks.

1. Since it doesn't matter who is the sender, it is not neccessary to verify the ECDSA signature for such transaction. This wasted about 6000 gas.
2. The attacker may run out the sponsor balance by submitting invalid signature.
3. The supporting for ed25519 must be implemented by the contract developer. The ed25519 account can not act like a normal account in Conflux Network.

So, we have the following CIPs:

• CIP-45: Introduce Flexible Account Authorization Methods. This CIP proposes to support SECP-256k1 directly.
• CIP-52: Customized Rule for Eligibility to be Sponsored. This CIP proposed to allow the contract developer to specify a short script to check if the sender can be sponsored. All the miners should avoid packing. In the implementation view, we need to replace checking whitelist by running short script. (We also needs some design for backward compatible.) This CIP can support all the use cases in EIP-2938 and solve the second drawbacks in our example. A side effect for this CIP is this enables the contract developer customize the sponsorship rule. E.g., only the addressed staked enough contract token can be sponsored.
• TBA, a CIP for drawback 3.

[ChenxingLi]

Closing due to inactivity. Feel free to comment if you'd like to continue the discussion. Thank you!