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 are the 5th and 6th iterations of the idea.
Fifth Iteration
These are some advances the Etherplan Coin (EPC) team has done while brainstorming the idea:
1. The Etherplan Coin miner chain or EPC chain serves as a hub that serves as a “source of truth” which is an analogy for keeping the state updated for the whole system.
2. As the hub, it must have a record of all transactions occurring on the EPC chain itself and the various smartKs in the various EVM chains.
3. The reason for this is that, to be able to have the ability to move coins from one EVM chain to another, the hub needs to be aware where the coins are (i.e. at the end user accounts level) in the various chains to verify whether there is a balance and if they were burned before issuing them in another chain.
4. Users can enter regular ERC20 transactions to move coins within any EVM chain internally. To do this they need to make the EPC chain hub aware of each transaction by sending first the transaction to the hub, then receiving a proof that the data was received at the hub, and then sending the transaction with the proof to the corresponding ERC20 contract in the EVM chain to move the coins internally (the ERC20 contract will be programmed so that it does not move coins if such proof is not present).
5. To do interchain coin transfers from one EVM chain to another, users have to send a “transfer transaction” to the EPC chain hub. When this transfer transaction is processed at the hub it is then sent to the EVM chains so they update their state.
6. This “update” in the previous step means that one chain burns coins and the other issues coins in the indicated accounts by the original user.
7. These transfer transactions may include a miner fee for EPC chain miners so they include the transaction in a block.
8. The fee is paid in the EPC coin in the EVM chain of destination and burned in the chain of origin.
My concern in point 4 is that, because a transaction has 3 steps, the user may disconnect or something may go wrong and the EPC chain hub is aware of a movement in a chain, but it is possible that the user then never sent it to the corresponding EVM chain. A way to see this is that any user would lose their coins if they do not complete transactions, so it is their responsibility to complete the three step transaction.
Sixth Iteration
The Etherplan Coin (EPC) blockchain is also an EVM compatible network.
I think the idea of having EPC nodes host at least the chain of headers from every other supported EVM chain is possible. If the EPC network tracks another 10 EVM chains, however, it seems like a lot (there were concerns about this kind of scalability problems), but if only some are required to overlap for this then I think it is at least worth considering.
Other than having different network IDs and chain IDs, all EVM networks seem to be the same gossip network, and I actually think they all receive all traffic, but they just drop all that are not their chain and network ID.
The concept of SPV, FlyClient, and NiPoPoWs are all about receiving less than the full history from the other side for verification; this means that maybe tracking just the last N transactions of the other EVM chains would make sense as well.
As the EPC chain only wants to interact with specific satellite ERC20 contracts in each EVM chain, I wonder if only the transactions from those specific smart contracts could be replicated on the EPC chain side. In other words, just track the activity of the EPC satellite contracts inside the selected EVM chains.
Regarding the Complexity of the 3 Step User Transaction
1. If some EPC chain nodes are running all nodes (whichever full or abbreviated model from above) from all selected EVM chains as well, and if that means users could send the three steps in one transaction type to single IP addresses, that would be good as it seems the risk of dropping parts of the transaction would be practically eliminated.
2. The 3 step transaction type, whether consolidated as above or separated as before, in any case does not match the format of regular ERC20 transactions, this means that the classical wallets and dapps everyone uses; such as MetaMask, MyEtherWallet, MyCrypto, Coinbase, Exodus, Blockchain.com, Uniswap, SushiSwap, Yearn.Finance, etcetera; would probably have to integrate this new kind of transaction type. This does not seem good for the initial cost of marketing and penetration.
Code Is Law
