SHA(ZAM)!

A network of Champions to guard your State Channel.

I choose YOU as Champion of my State!

I am a big fan of the Gas Station Network for meta transactions. It simplifies greatly the problem of dealing with the game mechanics of trust for a decentralized meta transaction relay network. In particular, I really enjoy the way in which DApps are responsible for deciding which relays they want to use, as well as for deciding when they are being abused, all without needing to give up any security guarantees.

Read more about Gas Stations Network, and Zeppelin’s Participation in the Gas Station Alliance.

Lately, as I’ve been building demo’s on top of the Gas Station Network, I’ve been wondering if we couldn’t use the same kind of mechanisms to support layer two solutions which typically are backed by complicated game mechanics and native tokens.

A problem with state channels is eloquently explained in this paper by L4 Ventures as Liveliness and Availability. Basically, if you have a state channel open between two parties, you’re relying upon both parties being online, as well as willing to communicate with one another.

This is important because the security guarantee of state channels depends on the fact that if two parties disagree, they can always return to the main net to prove the most recent valid state during a period of time known as the ‘challenge duration’. If however, one party is unable to connect to the network (for example they lose internet connectivity or they close their browser) then the party that still has connectivity can present a transaction on a chain with an old state, and the second party without connectivity either won’t know, or isn’t able to challenge an invalid state.

If both parties lose connectivity (or worse) their funds could end up locked in the deposit contract indefinitely.

The Gas Station Network functions with a singleton contract which contains a registry of all relays willing to relay transactions for a fee and some slashing mechanics to avoid bad behavior.

DApps are free to choose any relay they wish, and if the relay misbehaves, not only can it not steal the DApp users fund, but the DApps is free to blacklist the relay if it decides it is being abused.

The system is really quite elegant, is currently being audited by Zeppelin and at most bad behavior can cause a DApp to lose only a couple seconds of time and no funds.

I choose YOU as CHAMPION! (Of my State)

DC Comics

So what happens if we merge the best part of the Gas Station Network with the worst part of state channels? Well, Billy ETHson, I choose YOU as champion (of my most recent valid state)!.

DApp users are not very good custodians of state, nor are they very reliable when it comes to uptime either. Users connectivity can vary wildly, and if the browser window closes, *poof* that users state is gone.

With, what I am calling the “SHA(zam)!” network (pending litigation from DC Comics of course!) when two users open a state channel between themselves, they can also each nominate a relay as “champion” to protect their state in the case of loss of connectivity or malicious behavior on the part of their counterparty.

Let's take an example:

Alice decides to open a state channel with Bob for a game.

First, both Alice and Bob make a deposit into a contract (let's call it the Hub of Champions, like the Relay hub in the Gas Station Network). Alice looks at the ‘Hub of Champions” and randomly selects a “champion” to defend her state. At the same time, Bob also goes to the “Hub of Champions” to select his “champion” to defend his state.

Alice and Bob can transact off-chain, at high speed and no cost, the same as a normal payment/state channel.

The difference is, that for every transaction Alice and Bob make between each other, they send a copy to their respective Champions for safe keeping, as well as regularly pinging their respective Champions with a ‘keep alive’ to let them know “all is well”.

If either Alice or Bob fails to check in with their respective Champion, their Champion can assume something has happened and submit the most recent valid state they have received to the network to start the challenge process of closing the channel.

In the case of being meta-transaction powered, at this point, Bob or Alice can request their Champion to also pay the cost of gas for this transaction.

So for example, if Alice loses internet connectivity and fails to check in with her Champion, after some period of time, the Champion will submit the most recent state it has received from Alice to the deposit contract to close the channel.

Meanwhile, Bob’s Champion should notice that the challenge period has started, and subsequently submit it own latest copy of state it received from Bob to the deposit contract. The most recent valid state is confirmed and the network executes it. Meanwhile, both Champions receive a payout as a fee for having facilitated the “championship”.

Champions are incentivized to watch the deposit contract closely, as state-channels that are closed without both Champions could penalize the ‘lazy champion’.

What is nice about this setup is that it is very simple to reason about. Alice and Bob don’t need to trust one another, and their respective Champions don’t need to know one another. It is also each participants responsibility to choose their partners wisely.

As in the Gas Stations Network, DApps and Relayers (Champions) are free to determine who they want to work with, as well as when they are being taken advantage of.

Note, this is a fresh idea (fresh as in new AND cool), so obviously there are edge cases for bad-actors and attacks that need to be better thought through but in general, the system should be pretty easy to make secure and robust enough for most use cases.

Say my name so my STATE CHANNEL may flow through you! (Image Credit: Warner Bros)

Some things that come to mind:

• What do you do if a Champion disappears in the middle of an open-state channel? If Bob’s Champion disappears, he would be free to select a new Champion and forward his latest state copy to the new Champion. The DApp could then decide to black-list this Champion if the behavior is common across DApp participants (or even slash Bob’s Champion). If Bob’s Champion submits his state early, before the game finishes, the DApp could detect this and submit a proof that the state channel was still open (a newer transaction from Alice for example) which could be used to penalize the Champion.
• Alice and Bob are free to individually select as many Champions as they wish so long as they are all properly compensated. This would increase security (peace of mind?) for higher value transactions. While I prefer to avoid fancy game-theory if multiple Champions are chosen, then some sort of provable punishment mechanism could be implemented to prevent misbehavior between Champions aligned to serve the same user.
• The entire process could be Meta transaction friendly.
• The idea could possibly be friendly to generalization. At the start of the state channel, both Alice and Bob could sign off on a deterministic state transition machine which could either be run by Champions, or directly on chain. The Champions could compute each valid state to form a transaction which could be validated on-chain (or other Champions of Champions! totally thinking off the top of my head here….).
• State Channels of more than two parties could allow one party to exit the channel by having a Champion front the exit cost of the user who wishes to leave early and reclaim their funds without closing the channel.
• Champions could even send back signed transactions of the latest state to the Bob or Alice as “proof” they were acting honestly. In this case, Bob or Alice would always be free to publish this proof themselves. This works much like the GSN network, where if there is a delay in receiving a signed transaction back in response, then the DApp can have a strong suspicion of malfeasance. At that point, it could select a new Champion, or move to close the channel with their last valid state that they received back signed.
• Something that needs to be considered is if there is a vector for an attack in case you pick a Champion which is colluding with your counterparty. Ideally, there would be so many Champions that it would be unlikely for two parties to select the same Champion. Partial mitigation to this problem is that users can also freely challenge and return to main-net to retrieve their funds from the deposit contract. Another potential solution would be forced randomness in the selection of Champions to prevent the encircling of any one user.
• In its current description, this system isn’t as private as a normal state channel transactions might be as the Champions are both privy to at least half the state transitions. For simple transfers of value, this most likely isn’t a problem as it is no less private than the final transfer of value between Alice and Bob back on the main network. For complex state transitions, it might be necessary to come up with a privacy-preserving layer to hide the state transitions from the Champion itself.
• Possible front running by Champions (not that this necessarily introduces any vulnerabilities) could be solved by having Alice and Bob share their state updates with one another before sharing them with their Champions.
• If Alice tries to cheat by sending her Champion a different signed transaction than she sends to Bob, her Champion will end up holding an invalid state and will no longer be able to help Alice in the event she loses connectivity. The Champion will still be able to get paid, despite trying to submit an invalid state, as the state will be signed by Alice. In this case, the Champion can either slash Alice or decide not to be her Champion in the future.

Practically, however, there is very little incentive to cheat. The Champions can grow a reputation (possibly managed on-chain) of being reliable and thus become ‘favorites’. Champions could pool resources, ‘covering’ one another in case of accidental unavailability. DApps could purchase insurance against something catastrophic, or just as a cost of doing business. Champions can’t access user funds so they are incentivized to try and be as efficient and reliable as possible.

They can also set their own fees, potentially even paid in tokens (Dai!) be it a per-transaction basis or a duration of time. More complicated state transition models could be created and shared between State channel participants and Champions to enable larger numbers of participants.

I imagine, most likely Champions will actually be the DApp service providers themselves, allowing their users to interact in a decentralized way, but providing the infrastructure to enable this when their users are running DApp on unreliable systems (such as mobile web browsers).

So that's the idea for “SHaZAM!” The network of State Chanel Champions. The next step would be to create an ERC and then to create a demo.

Reach me on Telegram or Twitter if you want to chat more about it!

I am Developer Advocate Zeppelin.

SHA(ZAM)! was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.