Tezos pay to contract hash (p2ch) Accounts

Research and Development
1

ERC-4337 (aka Account Abstraction) has been quite a hyped topic in the EVM/Ethereum community, highlighting benefits of improved UX and the ability to unleash the adoption of the next billion users.

While I believe the way it was introduced on EVM chains is still treating smart contract accounts as second class citizens, the benefits are real and the concept very relevant also for Tezos. However I believe that the real killer feature for Tezos behind this concept is the ability to allow any EVM user to interact on Tezos without changing their tech stack. Or spelled out differently allow any EVM user (ETH, Polygon, BSC, Arb…) to interact with Tezos dApps with their EVM account. In order to make this happen I propose to introduce a change to the protocol called “pay to contract hash”, which draws its inspiration from Bitcoin’s “pay to script hash” (P2SH) and Taproot. In a nutshell what it means is to introduce a new kind of account (i.e. KTX or tzX), for which the way the address is calculated is: prefix + base58(hash(contract code | contract storage))
To be a valid p2ch contract, the contract needs to have at least one entrypoint “call(callData:bytes)”. Only operations that yield a valid execution of “call” will be included in a block.
To create transactions (i.e. native tez transfer), this account has to:

  1. call the “reveal” operation with the matching code and storage as parameters.
  2. invoke the “call” entrypoint with the respective payload as parameter.
    All operations’ gas consumption and storage are paid in full by the account itself.

While this seems like a small change, there are some nice properties:

  1. The user can deterministically generate a contract account address without having to deploy it first.
  2. The contract account can by itself pay for the origination and storage
  3. The contract account can by itself pay for operations
  4. No EOA is needed → no private key → next level of adoption
  5. You have native smart contract accounts which wallets can use to offer an improved UX (and also gives them the possibility to monetize the wallet).

One potential issue with the proposed change is that a baker needs to simulate the “call” before being able to include the transaction, this is different for an EOA transaction because fail or valid the account’s balance will always cover the gas - this is not possible in this case because an attacker could drain your account. However the maximum this costs is the set operation gas_limit, which we could limit for p2ch operations.

A project like Acurast, can then use something like Hyperdrive (Introduction | Acurast Hyperdrive Documentation), to offer every EVM user transparent access to Tezos dApps. Allowing us, the Tezos community, to address a way bigger market of users. Because let’s face it in the end the user does not care about the underlying technology, but does very much care about the UX and convenience.

I believe this will unlock a big audience for Tezos and allow projects on Tezos to market their solution to the broader crypto ecosystem. Ultimately it also means that developers can choose to build on Tezos without having to worry about the size of the community.

Let me know what you think

5 Likes