In different documents, we find discrepancies in the question of how many parties a state channel can have. The main document in the description of the protocol indicates a restriction of two parties. In posts on the forum and blog, as well as in earlier publications, several (more than two) parties are mentioned. Which option is correct? If there are two sides, how good and cheap is the opening / closing of the multiplicity (thousands and millions) of channels of states from the point of view of performance?
We are asking this in the context of the fact that we will need to redistribute some amout of tokens from one large set of users to one or more another large sets of users like functionality of multy-signed contracts.
Hash-lock mechanism like this is described in aeternity whitepaper, but we can’t find any information about its technical implementation.
Hi @aiii,
You are right that some contradicting descriptions for channels can be found and those address current channels and the vision we have for them.
As for the main net launch - there will be channels with only two participants. There are plans to expand them to a couple of participants but this will be afterwards. Since every state change is to be co-signed by all participants in a channel - it would not be a good idea having millions of participants in a single state channel because if one of them goes offline - no off-chain update can be performed.
As for the price of opening a state channel - it requires a single on-chain transaction. Once opened - participants can enjoy the channel’s off-chain blazingly fast transactions. Closing it requires another on-chain transaction.
Channels are much more than a peer-to-peer connection.
Yes, you can put tokens from your balance to the channel. You will be able to do it in a various ways - via a transaction or a contract for example. This will reduce your balance and the tokens will become part of the channel’s balance.
Once the channel is created - a uniq_channel_hash_id is created for it. You can think of it as the channel’s address. From then on, you are to use it in both your on-chain and off-chain transactions regarding this channel. Ex.:
The channel is a first class object in AE, so you have a couple of different on-chain transaction types that referrence the channel (by its uniq_channel_hash_id): you can deposit tokens to it, withdraw tokens from it, snapshot it, and close it in a various ways.
Off-chain you can transfer tokens to and from the other party, you can both call contracts and etc.
These all have the uniq_channel_hash_id involved, treating it as an independent on-chain entity (which it actually is). From the chain’s point of view the channel is a mutly-party account that has its own special rules for operations and distinct transaction types.
Now regarding WebSockets - channels have 2 parts:
Protocol for creating, updating and closing channels on-chain. Those are the expected transactions in order for one to operate a channel on-chain and enjoy its strong dispute resolution capabilities.
Various implementations of channels that comply with the bullet point above. These might or might not be based on WebSockets. The important thing is that you can sign a correct offchain transaction, the medium used is not enforced in any way. You could do it even on a piece of paper Our implementation for channels does use encrypted WebSockets but this is not a requirement, you can use a channel implementation of your own.
If you have further questions, I remain at your disposal.
This is depending on what type of example you want.
In order to have a valid state channels - the on-chain protocol must be satisfied. Everything beyond that is to make our lives easier.
If you want an example for how to write yourself a service that acts as a participant in a State Channel - I can not show you example code for that.
If you want to build an app that consumes the WebSocket APIs - you can check this as it covers all the communication between participants for opening, making a few off-chain payments and closing the channel. This is a simple synchronous JSON-RPC WebSocket protocol you can build your apps on top of. You can consume this API using any stack that provides WebSocket support.
If you want a JS example - you can check this pull request. Please keep in mind that it is still work in progress, so it is not polished, it does not communicate with a wallet and etc. I am not sure what its fate would be and it could as well be a throwaway example - I see it is based on roma release Nevertheless - you can draw a lot of inspiration from there.
Our implementation for channels does use encrypted WebSockets but this is not a requirement, you can use a channel implementation of your own.
Nevertheless - you can draw a lot of inspiration from there.