Improvements for pEthereum

The pEthereum is a powerful protocol of Incognito. In the first place, it’s designed to bring privacy to other blockchain’s dApps (e.g., pUniswap, pCurve, pPancake, etc). Then we are also leveraging the protocol for building the Incognito’s core product - the Universal Swap.

For that reason, improving pEthereum’s design would make a meaningful impact on many aspects of Incognito. In this topic, let’s dig into a few improvements that will promisingly help:

  • Speed
  • Fee expense
  • Reliability
  • Privacy
  • Decentralization

Current pEthereum’s design for bringing privacy to other blockchains dApps.

In the old design, it needs three procedures (DEPLOY, EXECUTE, UNDEPLOY) to be able to use privacy coins in EVM blockchains’ dApps:

  • DEPLOY is the process of moving funds from Incognito to an EVM blockchain so that users can spend them in dApps.

  • EXECUTE is the process of anonymously running a function call of an EVM smart contract. For example, running swap (pETH, pDAI) on Uniswap anonymously or borrowing (pUSDC) on Compound anonymously.

  • UNDEPLOY is the reverse process of DEPLOY: moving funds from an EVM blockchain back to Incognito.

Executing three transactions may also increase the likelihood of failure, expensive fees, and lower speed as compared to executing a single transaction only.

Also, moving the returned funds from an EVM chain to the same Incognito payment address (UNDEPLOY) would break unlinkability and even untraceability.

Lastly, users need to manage EVM keychains for receiving funds after DEPLOY procedure and signing needed data during EXECUTE, UNDEPLOY procedures. This is friction in UX that needs to be solved by using temporary keychains managed by the Incognito team that reduce decentralization.

Improvements with new workflow

The problems described above indicate that there still is room for improvement and the main question is: what if we merge the above three procedures into a single transaction?

In essence, the main workflow, illustrated in the above diagram, doesn’t change much compared to the old one:

  1. User creates a transaction to Incognito chain to burn privacy coins
  2. Incognito chain produces a burn-proof
  3. Relayer gets the burn-proof and then creates a transaction for submitting the proof to an EVM bridge smart contract.
  4. The smart contract verifies and then relays calldata to a dApp’s smart contract for execution.
  5. According to the “BurnForCall” request’s parameters, the smart contract will either emit an event for re-shielding to Incognito or send returned coins to the designated address (“withdraw address” parameter)

Let’s only analyze changes to see how the new design improves the aforementioned problems:

  • First of all, we are merging the logic of DEPLOY, EXECUTE, and UNDEPLOY procedures into a single transaction that is illustrated in the red border. Therefore, we will be able to address the first three problems regarding reliability, fees, and speed immediately.

  • Users also won’t need to manage temporary EVM keychains since intermediary steps are being removed from the process. In other words, no temporary EVM keychains needed will remove centralization.

  • Different receiver one-time address (“receiver (OTA)” in the “BurnForCall” request) for every request, which will prevent observers from linking multiple transactions to the same user so the unlinkability and untraceability are preserved.

  • Lastly, a new option that entitles users to withdraw to an EVM address (defined by “withdraw address” in the “BurnForCall” request) will increase flexibility. For example, a user can swap USDC from Incognito for ETH with Uniswap in Polygon network and then withdraw the receiving ETH to his/her Polygon address in a single transaction. This is not possible in the old design. Additionally, the option may also help reduce waiting time and fees by skipping the re-shield step.

  • Please note that although the design is described specifically for EVM blockchains, it can be readily applied to even non-EVM ones with some code modifications to accommodate the change in programming model.

Closing thoughts

In this topic, we’ve just discussed the known problems of pEthereum’s old design and proposed a new design to address them. We expect that the improvements will bring much better experiences (a.k.a faster process, lower fees and better failure handling) to users when using Incognito’s cross-chain products, especially the Universal Swap.