WIP Introducing StateNET; State channels for verbose off-chain apps
This is a draft lite-paper thing for StateNET, a stateful implementation of state channels. While other state channel solutions have basic fraud proving mechanics, StateNET allows for full on touring complete fraud proofs. This makes them usable for DeFi, gaming, storage (think SIA), and more!
StateNET
StateNET is a real-time scaling solution for blockchains. It’s goal is to move computation of transactions completely off chain, while inhereting all security properties of the host blockchain via strong fraud proofs.
StateNET transactions are agreement between two parties about some shared piece of state they both own on-chain. These can be token balances, NFTs, smart contract execution, or any other type of data. StateNET allows it’s participants to define complex settlement logic. This approach allows us to go beyond payments, and enables uses like gaming, DeFi, and more.
Overview
StateNET(refered to as “SN”) can be implemented on any blockchain that has support for stateful smart contracts. The spec described here focuses on an implementation for EVM blockchains.
We describe how SN functions in the context of payments, but as the system is generic, it represents ownership of the value of storage slots on chain.
Channels
SN works by establishing channels: two participants create a channel that represents some ownership over a shared piece of state on the host blockchain. The data can only be modified either by mutual cooperation or unilaterally on-chain.
Initially they each hold a SN transaction that gives ownership of the data (e.g. 1 ETH) back to one party. They can later sign a new SN transaction that splits these funds differently, e.g. 0.9 ETH to one party, 0.1 ETH to the other, and invalidate the previous SN transaction so it won’t be spent.
Conditional transactions
SN channels are agreements between 2 parties, but they can be connected in order to form a network of all people with SN channels.
This requires conditional transactions, which can be added to a channel, e.g. “you get 0.1 ETH if you reveal the secret within 6 hours”. Once the recipient presents the secret, that transaction is replaced with one lacking the conditional payment and adding the funds to that recipient’s output.
Forwarding
Such a conditional payment can be safely forwarded to another participant with a lower time limit, e.g. “you get 0.1 ETH if you reveal the secret within 5 hours”. This allows channels to be chained into a network without trusting the intermediaries.
Time-critical applications
Uses that require near real-time state updates, like games, can greatly benefit from such transactions. StateNET channels can be opened in such a way where one party can not perform a DoS by not signing transactions.
Lite-Spec
Contracts
The state/data
Channel
Opening
- give ownership of assets/values/slots whatever to contract
Closing
- if both parties cooperate, great success! we can settle the channel and get instant finality
- if not then see:
Disputes
When a StateNET channel is opened, both parties must agree on a mechanism to fall back to in case the channel is not closed cooperatively.
When one of the parties wants to close the channel unilaterally, they first must submit an on chain transaction with their claimed head. This means they’ll post what they think is the latest state of the chain before the other party has stopped cooperating.
Once this is done, a challange window opens where the other party can submit counterclaims. A counterclaim is simply a SN transaction that statisfies submitter claimed head nonce + n. If the other party submits a claim that was signed by the initiator thats newer than the claimed one, the channel is settled in favour of the counterclaimant.
This creates a very secure system that heavily punishes any kind of bad behaviour. If an malicious actor wants to double spend by submitting an old state, they have to rely on:
- The other party being offline.
- That they aren’t using a watchtower.
Checkpoints
Checkpoints are StateNET transactions posted on-chain, that do not close the channel. They can be submitted at any time by any party and give finality guarantees.
Once a user submitts a checkpoint, it goes through the same challange window a unilatteral close does. Once the window passes, we can assume that the checkpoint is valid. If either party tries to perform a unilateral close before the checkpoint, we can instantly reject it as invalid.
This gives us additional security when doing important state changes. By finalizing history, we guarantee state can not be reverted until the checkpoint.
Idea dumpster
Computation
We need to make sure that the off-chain execution is correct while being time-and-state dependent. Both optimistic and zk way of proving things make sense in different contexts and neither gives us guarantees that the state hasn’t changed after them. They could be time locked but that introduces its own problems. SN should be generic in the way it proves things so both should be supported.
