Within æternity, we have put an extra focus upon an important feature of the æternity Blockchain: State Channels. We would love to hear your ideas regarding possible use cases, implementations and maybe even possible partnerships!
State Channels are two-way interaction channels between two parties. State Channels make it possible to execute smart contracts off-chain, without fees, while keeping the same level of security that the blockchain already provides. Find more information how to use State Channels in our Introduction to State Channels here.
You can think about use cases regarding messaging, payments, streaming, gaming, etc. If you think you have a good idea, don’t hesitate and comment here!
Is privacy achieved if I open a state channel to send one transaction? I know what happens inside is private but are the end result addresses shown publicly?
Well, the old whitepaper mentions API micropayment as an application of state channels… for Ethereum there are similar systems such as machinomy. Some concerns I have about this are:
What is the advantage of micropayment channels from the API provider’s perspective, compared with the traditional solution of paid API accounts + a constant authorization token being sent with each request?
One naiive way to implement API micropayment with AE is: First the customer opens a channel with the service provider, and then with every API request, customer sends a new signed channel state, which grants the provider the total cost for all previous requests plus the current one. Provider also keeps track of the amount the customer owes him and processes a request if the request grants him more than the provider thinks he is owed. Problem here is it turns something stateless - a HTTP request / reply - into a stateful network protocol. The process making the request needs to know how much the provider is owed in total.
Alternatively, on each API call the user could send a payment token (a string), whose hash is hardcoded into a contract that lives in the channel. The provider could redeem the tokens at the contract, in any order, for payment. One token would be worth one call. The problem here is that a force progress is likely to cost more than a payment is worth… so this only kicks the can down the road… the parties still need to exchange signed channel states that represent how much the service provider is owed… so its the same as the above option just more complicated?
The old WP says something about “API micropayments enabling new types of business”. I wonder what you had in mind then?
Hi @LiuYang.chain
Since an encrypted network connection is persisted between participants, it should be really stable but since data is split into messages and every message is encoded and subsequently decoded onn the other side, it will require some more computing power than just sennding the file.
This is not tested so I don’t have any numbers
In order to open a state channel off-chain, you need to lock some tokens in it. To do so you are posting an on-chain transaction with your pubkey, the amount you’re dedicating to the channel, the pubkey of the other party and the their initial channel’s balance. So yes, currently the other participant’s pubkey is shown publicly. This is to change once we have virtual channels and a channel’s network - then you would be able to open channels in a more private manner.
Note that although channels do provide a certain level of privacy, at this point they shall not be considered private: if a dispute arises between the parties and one of them decides to use the blockchain as an arbiter - the latest off-chain state becomes public. This could be further improved with some zero-knowledge proofs, but those are yet to be discussed.
I find micropayments a really exciting feature. You are completly right that at any point of time both the user and the service provider must know their balances inside the channel, but this is part of the channel’s protocol anyway. In order to make this practicle, the:
client needs some software that handles this for him. Think of a wallet
the service provider needs software that is channel’s aware that produces tokens on demand
So whenever the client requests a new API token, this request consists of a some sort of a micropayment inside the channel: modifying participant’s balances or/and some off-chain contract’s balances. This is co-signed off-chain transaction. Then the service provider makes another off-chain transaction providing the requested new token and claiming the amount locked for it. It is a matter of a business model if this token can be used a couple of times or just once.
You are completly right that in some cases when there is just a few aettos locked in an off-chain contract, a force progress will be too expensive and might not be viable. It is a similar situation if one wants to force progress a really big contract - this could require much more gas to store it on-chain than one might eventually get out of the contract itself. This is up to the participant to decide.
Regarding the new types of business - I was not part of the team writing the paper, so I can speculate what they had in mind. From talks with them, I could think of some examples:
Video/music on demand where you pre-pay for the next few seconds
Paying/Getting paid for services per second
Paying your rent/mortage/bills per second
All the things we are used to pay/get paid on a regular basis could easily be broken down into smaller intervals. The only reason one gets a paycheck once a month is it is too cumbersome to make it every day for example. But with channnels it is easy to achieve.
Hi @erik.chain
Yes, the arbitration process was part of the on-chain protocol ever since roma release. I would not feel comfortable calling channels feature complete (except of the virtual channels part) unless we have a well defined and tested dispute mechanism in place. You can read about it here. Any feeedback regarding the document’s completeness and if it is clear enough are welcome.
" If a malicious party sent a channel_close_solo or channel_force_progress_tx with an outdated state, the honest party has the opportunity to issue a channel_slash transaction. This transaction MUST include a state with a higher round number than the one being disputed, signed by all peers for a successful challenge."
It is not clear to me from a conceptual point of view how the actual arbitration will be executed (apart from the technical descriptions). If there is a dispute, a mediation needs to take place. How can æternity blockchain offer this? Would it be a jury system or an external service provider?
None of the above. It is built inside the blockchain itself, it is resolved automatically without a human making decisions.
Each new state channel’s state is co-signed, signaling that at some point of time both participants agreed that this had been a correct state. Arbitration is providing the latest co-signed state on-chain.
We use the round to check if a co-signed state is older or newer and participants are epxected to provide the latest state they’ve seen. If any of them is malicious and tries providing some old state that is more beneficiary to one, the other can provide a newer co-signed state and replace the malicious one. The latest stated provided on-chain is considered to be the last until it is replaced by an yet newer one.
That clears things up quite a lot, thanks Dimitar. I want to ask about special case where one party pays in advance for a physical service: Let’s say I’m ordering a TV and paying upfront for it. I sign to pay and the other party signs as well, but eventually I don’t receive the TV. How can this be solved? I was thinking of a multisig where a third party arbitrator (human!) would be required.
All interactions with the physical world could be hard to prove with blockchain, as it requires some infromation to land on-chain. Luckily enough we already have oracles that aim at doing exactly that. Probably it would be easiest to explain with an example:
Alice wants to buy a TV from Bob. Alice wants to keep her TV buying private so she will do it using state channels. Alice and Bob have an opened channel.
Let’s have Oliver, Owen and Ora. They all provide a service “did I get my TV or not”. They do it via Oracles - each one of them provides an Oracle and if you give it some information (tracking number?) it answers with yes/no if the shipment had arrived. They all have aquired enough reputation so both Alice and Bob trust them.
Alice and Bob put in their state channel a new contract. It says that Alice must provide the contract with a certain amount of tokens and then Bob will send her her new TV. When she receives it, Bob can get his tokens out of the contract. If she doesn’t receive it by a certain on-chain block height, she can claim her tokens back. The fancy part is the did she receive it: the off-chain contract in the state channel relies on an on-chain oracle(s) response. It could be just Oliver’s positive response, it could be 2 out 3 positive responses from Oliver, Owen and Ora - you can build a consesus from their answers.
So Alice and Bob have a channel with this contract. Alice deposits in the contract enough tokens so her order can be considered to be confirmed. Bob sends the TV, Alice gets it and now comes the interesting part: they ask the oracles in the contract on-chain if Alice had received the TV (more about the asking bellow). Let’s have them honestly saying “yes” (or enough of them being honest, enough being according to the contract implementation). Bob offers a new state in which he executes the off-chain smart contract using the on-chain oracle responses.
Happy path: Alice is honest she accepts the on-chain data and agrees to the new off-chain state. Bob gets his tokens in the channel. End of story.
Unhappy path: Alice is malicious and once she got the TV, she wants to cheat Bob with her getting the tokens out of the contract. She refuses accepting the new off-chain state. Then Bob simply prepares an on-chain force progress transaction, executing the off-chain smart contract on-chain, using the oracle’s responses. This produces the new off-chain state on the chain with Bob’s off-chain balance being updated accordingly. Then they can continue using the channel from this new state or rather close it.
Some notes to further clarify concepts:
if Alice wants to keep it secret that she bought a TV, isn’t it a privacy violation if she asks the orcales on-chain? The thing is it doesn’t have to be her asking it. It could be Bob. It could as well be Carol, if Carol provides a service “ask this oracle this question instead of me”, thus Carol separating Alice from asking on-chain by herself.
is this a private way of doing business? No. Since the dispute mechanism requires the contract and its state to be posted on-chain, the contract is not private if participants take the unhappy path
Edit: all of the described functionality is already present. It is actually present ever since roma
Thanks for the details Dimitar!
I had some follow up questions:
would you expect that integrating an oracle(s) is going to be common practice for using state channels? I know this is a super general question as it depends on all the different kinds of possible use cases.
when an on-chain force progress transaction happens, are all the previous off-chain states exposed? and I’m assuming that after the new off-chain state is in place, subsequent state updates are kept “private” for the remainder of the channel provided there’s no other disputes until the channel is closed.
Yes, I expect so. It might not be exactly as we imagine it, though. For example I speculate that there will be off-chain oralces that basically sign messages (and send them to subscribers, not posting them on-chain). Later on those messages can be used in executing off-chain contracts in channels - all you need is set in your channel off-chain contract the pubkey that both participants expect to be providing the signed messages and then you can progress its state both off-chain or in an on-chain dispute. This will greatly reduce on-chain traffic and open the door for various high-frequency oracle services (probably implemented via channels, as well).
For example Alice has a truck that drives medicines around. Bob provides insurance on the medicines: if the temperature in the truck goes out of some range - the medicines are considered spoiled and Bob covers Alice’s loss. Then we have a small thermometer that is being able to sign messages. It can measure the temperature in the truck every second and send this as signed message to both Alice and Bob. This doesn’t have to be on-chain (why pay the fees?) but it is yet an off-chain oracle I do imagine a ton of IoT oracle applications and some can post on-chain, others can be kept off-chain.
No, only the latest state is posted on-chain. We don’t validate the past but rather trying to split the tokens according to the latest state. Yes, once a new state is being produced on-chain - participants can either close the channel or continue from then on off-chain.
So was going through this thread and found it exciting. I have been working on similar use case, where a user (or developer) pay to API provider as per use. The challenge here is SPEED which payment channel can potentially solve.
Coming back to your question, “What is the advantage of micropayment channels from the API provider’s perspective, compared with the traditional solution of paid API accounts?” - What I felt is this. In order to build a better system, a developer might need service-apis from many API providers such as Google, Facebook etc (Imagine he is ML developer, he might need paid dataset APIs). In order to pay them, he has to provide his credit card details to all these providers and the activation takes time. Again if he wants to switch to another provider, he has to do all these process again.
With payment channel, he would not have to reveal his private details to providers and also the switching between the providers would be seamless.
Payment channels also are not centralized and trustless. Reusing your example: Google can deny of service, lock your account and etc. In the channel’s context you worst thing a participant could do is become inactive or actively malicious. For both cases there are clear protocols how a participant can be safe.
State Channels just take the Payment channels to a whole new level, allowing to have smart contracts in their state. And yes, real time smart contract execution on the blockchain for free is exciting, indeed
