Good writing, but it seems like a non-useful direction. See bold text at bottom of page
A channel is basically a mechanism where a group of nodes provably agree on a series of state updates and their order. At any point in time, any of the nodes can publish the latest agreed-upon state update to a blockchain. After a pre-agreed delay period the blockchain makes this state update permanent (for example, transferring escrowed funds to various accounts). However, if another node participating in the channel publishes a higher-nonced state update before the delay period is up, the higher-nonced update takes precedence. This means that participants in a channel can stop each other from cheating if they are able to publish to the blockchain at least once every delay period.
In Hess channels[1], a balance number is altered in each channel transaction to make payments between two parties. Channel transactions also include an array of hashlocks (or in the original spec, other "bets"), because otherwise each hashlock would have to block the whole channel.
Changing that one balance number can be considered a compression technique that happens with every transaction. It may be simpler to structure the channel as its own chain of transactions (aka subnetwork[2]) that happens just between the participants of the channel. This is then quite similar to the main cryptocurrency, but without blocks. Old state can still be condensed into a single balance number, as long as all participants agree.
Hess channels are explicitly between two parties. A subnetwork can be between any number of parties, both as transactors and validators.
The main attack on channels involves one of the parties publishing an old transaction that has a more favorable state than the latest transaction (a higher balance for that party). Hess channels mitigate this attack with a delay and a nonce field. A when a channel transaction is published to the blockchain, delay blocks must pass before the funds are actually transfered. During this delay period, a transaction with a higher nonce can override the transaction that was first published. This means that the parties to a channel can prevent one another from cheating by checking into the blockchain at least once every delay blocks.
{
channelId: String,
threshold: Percentage,
accounts: [
{
pubkey: Pubkey,
validationPower: Percentage,
balance: Float
},
...
]
}
Signatures: [ <everyone with a balance in the subnetwork> ]
The genesis transaction has an array of accounts, who play some role in the subnetwork. Each account has balance, which is how much money they are putting into the subnetwork, and validationPower which is their relative power to validate channel transactions.
threshold is the percentage of validationPower that must sign each channel transaction for it to be considered valid. This allows us to continue to process payments if some of the accounts are unreachable, making a tradeoff between security and performance.
{
channelId: String,
nonce: Integer,
state: ...
}
Signatures: [ <at least `threshold` percent of validation power in subnetwork> ]
For a subnetwork transaction to be considered valid, it must be signed by threshold percentage of validation power. state contains the state of the subnetwork. For instance, a simple channel allowing the participants to pass money back and forth:
state: {
[pubkey]: {
balance: Float
},
[pubkey]: {
balance: Float
},
[pubkey]: {
balance: Float
}
}
An issue here is that a majority of the validation power could conspire to steal the money of a minority. Other rules could be instated to ensure that a transaction must be signed by those nodes whose balances are reduced, but this whole thing is starting to seem unnecessary.