This is part of a series of articles that explain Etherplan Coin (EPC):
• Etherplan Coin (EPC): A Multichain Mineable Token – First, Second, and Third Iterations – March 24, 2021
• Etherplan Coin (EPC): A Multichain Mineable Token – Fourth Iteration – March 26, 2021
• Etherplan Coin (EPC): A Multichain Mineable Token – Fifth and Sixth Iterations – March 30, 2021
• Etherplan Coin (EPC): A Multichain Mineable Token – Seventh Iteration – March 31, 2021
Etherplan Coin (EPC) is a mineable token that may be transferred between Ethereum Virtual Machine (EVM) blockchains without depending on multi-signature schemes or trusted third parties.
Below is the 7th iteration of this idea.
Seventh Iteration
Following the previous iterations and the constraints I list below, I created an EPC interchain “transfer transaction” that goes the other way, first: The proof is sent by EVM chain SPV nodes to the EPC chain, first. Then, FlyClient/SPV proofs are sent back in the other direction to the EVM chains for them not to duplicate issuance.
Constraints
1. The EPC chain needs to be aware whether EPC tokens are burnt in the various EVM chains
2. As interchain transfer transactions are multi-step transactions, errors due to communication breakage between steps must be minimized. This means satellite EPC ERC20 contracts in the various EVM chains must be aware of burn transactions sent by the EPC chain as well.
3. Users must be able to send regular local ERC20 transactions to EPC ERC20 contracts in the various EVM chains to maximize compatibility with popular wallets, and to be able to use them in local dapps and smart contracts.
Dependencies
1. EPC chain nodes must also be SPV nodes of all EVM chains supported in the system.
2. All EVM chains must be SPV/Light Client enabled (which I think they are as Ethereum is: https://eth.wiki/en/concepts/light-client-protocol).
EPC Interchain Transfer Transaction Design Diagram
Explanation
1. EPC burn transaction: If the user wants to transfer n EPC coins from EVM chain A to EVM chain B, an EPC transfer transaction must be initiated. The first step of the transfer transaction is an instruction to the EPC ERC20 smart contract in EVM chain A to move n coins to the pending burn address.
2. SPV proof of pending burn transaction: When n coins are moved to the pending burn address, the user wallet receives an SPV proof that n coins have been moved to the pending burn address.
3. EPC transfer transaction with SPV proof of pending burn: After receiving the SPV proof, the user wallet sends to the EPC chain an EPC transfer transaction of n EPC coins from EVM chain A to EVM chain B. This transaction contains the SPV proof from EVM chain A, if not, or if it is not verified, then the EPC chain will not process the transaction.
4. Confirmation of EPC burn: When the EPC chain receives and verifies that the transfer transaction and SPV proof are correct, it sends a confirmation of EPC burn to the ERC20 contract in EVM chain A, which definitively burns n EPC tokens (send to a definitive burn address).
5. Order to issue EPC: The EPC chain also sends an order to issue EPC transaction to the ERC20 contract in EVM chain B, which proceeds to issue n EPC coins locally in the corresponding address indicated by the user if the EPC chain sent a FlyClient/SPV proof that it also sent the previous confirmation of burn address to EVM chain A.
How Are the Constraints Above Addressed
1. The EPC chain is aware that tokens are burned in EVM chain A before issuing new tokens in EVM chain B. This enables it to finalize the transactions and to serve as the hub for the whole system.
2. Communications breakage is minimized, and loss of coins reduced, by moving initially the coins in the EPC ERC20 contract in EVM chain A to a pending burn address. If the user sends a reverse transaction because the rest of the process broke, then the coins may be moved back to his account from the pending burn address after X blocks (say 72 hrs). If the transfer was completed (which should take no more than 60 to 120 seconds), then the user cannot recover burnt coins, ever. If the EPC chain dropped the EPC confirm burn transaction, then the order to issue EPC is never sent by the EPC chain because it only sends such tx after sending the confirmation of burn tx; it does not have proof of such confirmation of burn tx; and the EPC ERC20 contract in EVM chain B never issues n EPC because it did not get FlyClient/SPV proof of such burn transaction from the EPC chain. If the EPC chain dropped the order to issue EPC transaction in EVM chain B, then it can be sent several times until it is issued. Once issued, EVM chain B will never accept a new issue of such coins even if the tx is sent again repeatedly.
3. As the above EPC transfer transaction between chains is a different type of transaction than the regular ERC20 transactions, EPC users and wallets can send regular ERC20 transactions when they just want to transfer coins locally within EVM chains. They can also use the EPC coins with local dapps and smart contracts freely.
Conclusion
As you may see, to transfer EPC from one EVM chain to another requires at least 5 steps, but I think it isolates the “interchain transfer” transaction type and lets users use their EPC tokens as an ERC20 token as usual.
It seems that if EPC chain nodes may be SPV clients of all the EVM chains (this is much lighter than being full nodes and not all have to be) they can check for proofs in EVM smart contracts for the pending burn and burn transactions above.
This may, in turn, enable them to send back FlyClient/SPV proofs to the EPC ERC20 contracts (this is possible today if the EPC chain is SHA 3 + FlyClient enabled, which it will) in the various EVM chains, making the system pretty tight and secure.
Code Is Law
