Inspiration
Even if we use Plasma technology, there is a limitation on one child chain capacity. Inspired by Database partitioning, application partitioning, and Ethereum Serenity Sharding idea, there I tested application level aggregation of the multiple child-chains access.
What it does
Deposit ETH or ERC20 tokens on child-chains, each child-chain has its own deposit balance on the chain. By aggregating the balance queried from all the child-chains, the wallet app can show the total balance of the token. If needed transfer of the token, the app automatically generate suitable transactions on one or more child-chains.
How I built it
Based on my wallet core library (I am originally a mobile wallet developer), I developed a special wallet app accessing multiple Ethereum PoA networks (geth with PoA, Clique mode). It first access to the main chain (I used RInkeby for the demo this time) to look up a list of child-chains, then the app is configured to connect multiple child-chains per token in interest.
Challenges I ran into
The capacity limit of geth itself. Unstability of geth itself, or AWS server/network/IO capacity. Needed gas ETH on each child-chains, will need gas-abstraction in the future.
Accomplishments that I'm proud of
UI/UX, bridging people utilizing Plasma world seamlessly from the existing wallet apps.
What I learned
Using this approach will cause un-balanced distribution of token balances over the child-chains. I need optimization solution to "de-frag" the balances by exit/deposit maintenance, or direct inter-child-chain communication which is more complicated and needed some kind of sophisticated effort.
What's next for Single Node - Layer 2 Wallet for Scalability
Gas abstraction, refine UI/UX, improve private key management.
Built With
- javascript
- react-native
- solidity
- terraform
- typescript
- web3
Log in or sign up for Devpost to join the conversation.