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.

Share this project:

Updates