-
Notifications
You must be signed in to change notification settings - Fork 10
Fully Abstracted State Channel Components
This article is an overview of the components used in the generalised state channels approach developed at Ledger Labs from 2015-2016. The approach is partially implemented on Ethereum by the Toy State Channels project, although that project is not yet fully compliant with the finer details of this abstraction. Where this wiki differs in its descriptions from the functionality expressed there, it will usually be the case that the wiki describes the preferred method or the more general approach.
Here, we reluctantly follow the Ethereum convention of referring to individual coded objects as "smart contracts" for the sake of understandability. Readers unfamiliar with the convention should not understand this term as automatically entailing the existence of a binding legal agreement--rather the objective here is to create a design whose technical properties provide safety and security to participants whether or not they are also bound by contractual obligations and protections. For more information on the security models that state channels are designed to reproduce, see this article.
A multi-signature account or operation finds itself at the heart of most payment and state channel implementations. In order to ensure that no party to a state channel will experience unauthorised modification of "their" state, these mechanisms are configured to require consent from "n of n" participants (i.e. "2 of 2" or "7 of 7") rather than some lesser proportion (i.e. "2 of 3" or "5 of 7"). We therefore refer to this component as the "Unanimous Consent" object. It is the object which will be used to control or hold all state and digital assets which are to be "channelised", and the sole element in our abstraction which must be instantiated on a secure blockchain layer. Given a properly designed Unanimous Consent object, all other channelisable components can be created purely within the channel itself (though this isn't always the most efficient approach).
In addition to requiring unanimous consent before performing operations, there are some more subtle properties this object must possess. The object must be capable of performing multi-step, conditional operations (in other words, must be capable of more than just individual function calls). Consent, once given, must not be unilaterally revocable by just one or a few participants in the channel. In a fully abstracted model where multiple channels are operating in parallel under the same object, this also means that consents must not require or enforce a particular ordering to remain valid. However, consents must still be secure against replay considerations so that a consent to perform an action once is not used to perform it repeatedly. Consents must also be submittable by entities other than the consenting party themselves, since these are almost always received off-chain rather than via the chain itself.
Beyond fundamental requirements, there are also privacy and other considerations which influence the design of an ideal Unanimous Consent object. For example, does the consent process leak information about the total number of consents agreed to, even if not published? Or, does a partial consent necessarily contain information about what the completed consent will authorise? etc.
Special Note: as many other Ethereum developers are aware, the widely used wallet.sol "multi-sig" contract is not presently capable (September 2016) of maintaining multi-signature control over any operation beyond simply transferring ether (ETH), and hence cannot be used as a Unanimous Consent smart contract in a state channel scheme. As a result, the Toy State Channels project was forced to create its own alternative that more closely fulfils the desired criteria. However, there are significant privacy and security advantages of being able to utilise a standard multi-sig contract in the creation of a state channel. We therefore strongly recommend that any replacement aiming to become a new standard multi-sig contract for Ethereum implement the required criteria above, and support as many privacy-preserving capabilities and characteristics as practical.
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
Article still under construction