Getting Started with Blockchain | Generalized State Channels on Ethereum

State channels are the underlying technology available for distributed applications. They can be used to interact with a defined set of participants, such as payments or games like chess or poker. The "channelization" of these applications has resulted in significantly lower costs and reduced unacceptably high latency in today's blockchain applications, enabling user-like network-like response times.

Still, in today's Ethereum applications, state channel utilization is still low. Every project that wants to use a state channel must effectively build its own custom implementation, resulting in redundancy and unnecessary risk. Second, existing state channel implementations still place too many operations on the chain and otherwise compromise privacy.

Implement a privacy-protected, universal state channel built with modular components that support multiple parallel operations within a single channel and allow users to upgrade channel designs without any chain operations.

• Is the blockchain a scam?
• "The bitcoin dominance will continue indefinitely, and the 10-year survival history is not defeated by other currencies," said the chief developer of Monroe.
• Babbitt Column | Open Finance – Explore Bitcoin's Clearing System and Payment Process

By providing a framework and standard modular components for building secure, high-performance applications, developers can easily take advantage of stateful channels.

Our paper describes a state channel design that keeps the data chain as small as possible while remaining safe. We believe it will be a standard reference for building secure and optimized state channels, which is a long-term need of the Ethereum community.

State channel technology

The status channel works by "locking" a portion of the blockchain state to a multi-signature contract controlled by a defined set of participants. The state that is "locked" is called a state deposit. For example, this could be a certain number of Ether or erc20 tokens, but it could also be a cryptokitty or ENS domain name.

In the state deposit is locked, the participants of the channel use the out-of-chain message exchange and sign the valid Ethereum transactions without deploying them to the chain. These transactions can be placed on the chain at any time.

Updating the status of a channel is always done with unanimous consent. All parties sign (and retain their own copies) to trade under each chain. Because these "state updates" are entirely out of the chain, their transaction costs are zero and their speed is limited only by their underlying communication protocols.

Therefore, the status channel provides "instant" transactions, ie the parties do not have to wait for any blockchain confirmation. The application can immediately take the completed operation and display it to the user without waiting for a confirmation of the set number. This is how the state channel provides a web-like response time.

We call it the instant end. In the consensus study, “finality” refers to the extent to which state transactions are not reversed. In the context of a state channel, if Alice cannot be prevented from implementing operations on the blockchain (if they choose), then the operation is final.

If the latest "update" of the state channel means "alice=5eth, bob=1eth", then the status is "final". Remember, an update is a valid transaction signed by Alice and Bob, and any party can deploy it on the chain at any time. As long as we assume that Alice can broadcast the transaction to the Internet at some point in time, she can treat the transaction as a final transaction.

The core attribute of a state channel is to return to the blockchain only when necessary. If a state channel is properly built, all parties can perform fast operations with immediate termination. If there are any issues, the parties can always choose to deploy the latest version of the state to the blockchain.

Minimize chain operations

Existing application-specific stateful channel implementations require users to open a new channel for each application they want to use, paying for expensive transaction costs. For example, two users will conduct a chain transaction, open a payment channel between them, and they need to conduct another chain transaction to make a game.

Our state channel minimizes the need on the chain to the extreme, transferring as much logic as possible to the outer layer of the chain. This led to one of the most important points in our paper: a sufficiently powerful multi-signature wallet is the only necessary on-chain component for any single state channel.

Moving the logic away from the chain gives us a greater advantage over existing channels. We can install new applications into a state channel without chaining. We can even upgrade or redesign a state channel without the need for chain trading or fees.

This approach also has significant privacy advantages. Properly constructed, a multi-signature wallet used to guarantee state deposits should be indistinguishable from any other multi-signature wallet. On the chain, there is no way to distinguish between common multisigs and multisigs used to create state channels.

Counterfactual technology

We can use the so-called "fact-factual instantiation" to achieve these results. Explaining this technique requires first defining the terminology.

"Counterfactual" means that it may be true, but not. This is a very useful concept when discussing state channels, and we spend a lot of time reasoning about what might happen on the chain, but that's not the case.

In the status channel, we call "counterfactual X" to describe a case where:

1. X may happen on the chain, but it won't happen
2. Any participant can unilaterally cause X to occur on the chain
3. Therefore, participants can behave as X occurs on the chain

For example, imagine the payment channel between Alice and Bob. Alice sends 4 ETHs to Bob via the channel, which actually means that both parties have signed a deal. Either party can deploy this transaction on the chain at any time, but this is not the case. So we can say "Alice who gave the facts gave Bob4 ETH". This allows them to act like transactions that have already occurred – in the appropriate threat model, this is the final deal.

Counterfactual instantiation

In the above section, we said that our approach allows you to install new applications into the status channel without any chain operations or fees. How can this be?

The key to this ability is our so-called counterfactual instantiation. In the above section, we describe the counterfactual transaction between Alice and Bob. But we can also create counterfactual contracts. Counterfactual instantiation refers to instantiating a contract without actually deploying the contract to the chain. When a contract is instantiated counter-factually, all parties in the channel are as if it have been deployed, even if it does not. This technique allows us to move almost all of the channel logic away from the chain.

Counterfactual instantiation is achieved by having users sign and share their commitment to the multisig wallet. These commitments indicate that if the counterfactually instantiated contract is instantiated in the chain, the multisig wallet will hold the instantiated contract and transfer the appropriate state deposit based on the status of the contract.

To achieve this, we need to cite the counterfactual instantiation contract in the promise before deploying the contract. To this end, we introduced a global registry: a chain contract that maps the unique deterministic address of any counterfactual contract to the address of the actual chain deployment. The hash function used to generate the deterministic address can be any function that takes into account the bytecode, its owner (ie, the multi-signature wallet address), and the unique identifier.

For example, we might have a contract "c" containing the bytecode and constructor parameter "initcode". The result of a function call to the registry using the parameter "initcode" is to add an entry to the registry; its key is the counterfactual address, and its value is the actual on-chain deployment address.

This gives us a way to reference out-of-chain contracts without first having to deploy them to the chain. We only need to do a lookup in the registry to see which address corresponds to the counterfactual address. In Solidity, this is simple:

Registry(registryAddress).resolve(counterfactualAddress)

Object-oriented channel design

Our channel design allows developers to adopt an object-oriented approach to state channels. Any single state channel will consist of several counterfactual objects, such as a payment channel object or a board game channel object. Because these are all examples of counterfactuals, they don't need to add fees to the channel – only the two parties need to sign the promise.

For example, Alice and Bob can choose to instantiate a contract in their channel at any time, for example, to define a contract for a chess game. They can then exchange status updates with each other, which references a counterfactual illustration game in order to actually play chess, all without the cost of the chain.

We believe that this object-oriented approach offers many notable benefits:

Application developers can plug in the core components required for each channel for well-defined API programming.

We can ensure that as long as the core components are rigorously reviewed and kept secure, errors in the application developer code can be isolated to the state it controls.

Application developers can reuse existing components through counterfactual addressing, just as they would re-use Taifang contracts, for example, a source of randomness that can prove to be fair.

Users can protect their privacy in controversial situations by simply linking the controversial objects.

We can access more points on the trade-off curve between messages delivered during normal operation and transactions that need to be published in the event of a dispute. In some cases, this allows us to spread the response to obsolete states across channels.

in conclusion

If you are interested in learning more about generalized national channels and counterfactual techniques, we recommend that you read this article. This article contains important things that we have not summarized in this article, including:

1. Sidechains and other technologies such as Plasma
2. Review existing state channel design
3. In-depth study of related threat models
4. Meta channel
5. Example structure of a generalized state channel

Source: Public Number: Blockchain Research Laboratory

We will continue to update Blocking; if you have any questions or suggestions, please contact us!