State Channel Security Models
Although in a broad sense state channels aim to provide similar security guarantees to the underlying blockchains on which they are based, this is not a complete description of state channel security. On the one hand, the higher level of "precomittedness" to availability that channel participants make allows the reduction or elimination of some on-chain security considerations (such as the requirement to wait a number of confirmations before considering certain actions final). On the other hand, it is common to design state channel applications which "lean" more heavily on local economic incentives among the direct participants than on-blockchain operations are normally required to.
This page describes a few of the many security models which seem to prove useful in creating or improving the performance of state channel based applications with real world applicability. Although the general rule is that relaxing a security assumption allows for tackling a wider variety of problems, selecting the appropriate security model to work under is often a complex empirical and engineering question combining considerations of performance and real-world user preferences and behaviours. If any of the terms that follow are unfamiliar to the reader, please consult the glossary.
A state channel exists in relation to one or more underlying secure blockchain layers. At minimum these layers must provide:
- Some set of digital state to which channel participants ascribe value (e.g. digital currency, digital identities, authorisations and permissions, etc.)
- A sufficiently complex, ideally Turing complete instruction set that can be used to control and/or modify the valued state. Efficient support for relevant cryptographic operations (such as digital signatures, cryptographic hash functions, etc.) is key.
- Some type of timelike element that can be used by the instruction set to prevent or delay execution of certain state-related operations for a predictable period of time, and to accurately order interactions with the layer (to some useful level of granularity).
- Extremely high confidence that certain state-related operations and instructions will be executed as intended. Note that this is not a purely technical requirement and can be heavily impacted by the economics and overall makeup of the layer's consensus mechanisms and participants.
- Eventual finality. That is, for a given category of adversary, a given quantity of participant risk, and a given probability of reversal, it must be possible to identify an approximate time period within which the probability of reversal for certain state-related operations will fall below the desired threshold (this guarantee is likely to hold only for a specific domain of adversaries, risk, and probabilities, and that domain will constrain the types of state channel that can be based on top of a given layer).
- Censorship resistance. It should not be possible for a malicious adversary to indefinitely delay or prevent execution of operations by a given user or with a given portion of the state (again this guarantee is likely to hold only for a given domain of adversary).
Failures in the above guarantees, while highly relevant to actual state channel security, are considered out of scope in the following models. In addition to assuming these guarantees always hold, it is also useful to keep in mind a set of working guidelines and considerations that can impact security models substantially:
-
Differing roles within a state channel have significant implications for the appropriate choice of security parameters. For example, channel users will not in general be highly available. They will be frequently disconnected and offline, often for large periods of time. By contrast channel providers are likely to be highly available, with redundant and resilient infrastructure. They may even be "availability bonded" so that they incur financial penalties for failing to be as available as they have promised to be.
-
On chain operations are, in general, quite expensive compared to off-chain operations.
-
The processing of cheap, automatable tasks in return for financial reward is likely to be heavily oversupplied. Hence we assume here that an efficient market for such problems exists and do not worry about specifying a particular participant to fill this role (for example, in counterfactual verification).
To be completed
###Security models
To be completed
###Comparing state channel security models with blockchain security models
When comparing a state channel mechanism with a reference mechanism which takes place purely on a blockchain, having no direct actions taken amongst participants directly except via the chain, there are several broad classes of categorisation to be made, including:
####strictly improved The ideal situation is that a state channel protocol offers no possible disadvantage to a participant when compared with its fully on-chain alternative. Protocols may be strictly improved only for a particular party / set of parties, or for all participants in the protocol.
####strictly improved within bounds X The next best outcome is the same as above, except that a maximum disadvantage of X (typically very small) may be incurred relative to the specifically referenced on-chain alternative. Ideally this disadvantage should occur infrequently (if at all) in the context where the protocol is to be deployed, yielding a net improvement in practice. As before, improvements and bounds may apply only to specific participants.
####improved under some model X Alternatively, while a state channel protocol might not offer strict or strict within tight bounds improvement compared to an on-chain alternative, it may offer improved outcomes under some specific model, such as when all participants are strict local maximisers. Provided that the model is appropriate to the context in which the protocol is deployed, it may then offer real advantages for particular participants when compared with the on-chain alternative.
####empirically better The weakest possible position in which a state channel protocol may remain viable is if it proves advantageous in some real world context despite significant trade-offs or theoretical weakness, perhaps by relying on the altruism of participants. In general, a protocol which proves empirically better in some context should be able to be converted to the previous category by formally specifying the model under which it is improved. Mere empirical performance in and of itself, while useful in guiding the design process, does not constitute a security model.
####empirically worse An improperly designed state channel protocol may, despite theoretical soundness, prove to under-perform an on-chain alternative, perhaps due to an inappropriate choice of model. Such protocols should be scrapped or re-worked.
####strictly worse In some cases, a state channel protocol may offer only disadvantages when compared with an on-chain alternative. Because state channels depend on the existence of a working blockchain layer, there is never any reason to operate a strictly worse state channel protocol. Such a mechanism should be scrapped or fixed.