We know that smart contracts can be executed in state channel.
But if one close the state channel maliciously, what will happen to the smart contracts in the state channel.
Will the smart contracts still be executed?
Another question :
Is the mainnet launch with the function of creating Tokens based on AE?
The idea is to allow “forced progress”, where a participant can solo-close or slash with a mutually signed state + a valid contract execution step, given the contracts and states available.
So e.g. assuming that Alice and Bob are playing chess, and Bob decides to bail out of the game just before Alice is to play the winning move, Alice can still force the winning move on the chain. Presumably, the contract makes sure that it’s Alice’s turn, etc., barring Bob from forcing an execution step that makes him the winner.
This is work in progress at the moment.
OK！
I got it!
Thank you very much!
Hope everything works fine!
my questions about that topic:
smart contracts will be created and maintained within channels right?
(or can already on mainnet deployed smart contracts be used within channels?)
I assume that there is a standardized way to open and close state channels and within those channels both parties can create their own business logic in form of smart contracts. so when closing and re-opening a state-channel and wanting to perform the same business logic as before I would need to again make the smart contract available within the channel, right?
according to my assumption that you use a standardized way to open / close channels it won’t be possible to send specific tokens (created through smart contracts on-chain) into the state channel and run business logic using them or am I false?
is there a way to use oracles within state channels? I guess no because oracle providers probably shouldn’t know about any details of the business logic between the two parties, right? whats your opinion about that?
Hi @marco.chain,
I will address your questions in their order of being asked.
Yes. We can have both on-chain and off-chain contracts. The later are created and maintained in a channel. Yes, this will be done for mainnet. You can actually try them out in the testnet - with some small details - contracts in channels are already working.
There are quite a few different mechanincs at play here: you can open and close a channel. This includes on-chain transactions. You can also disconnect from the other party and reconnect again once you want to work with it again. This does not require any on-chain transactions.
Main difference is when you start a brand new channel, it is with an empty state - basically just the two participants’ accounts with their balances. If you disconnect and later on reconnect - you continue from the last state you both shared. You can use the different mechanics for different use cases.
As you put the question - no, you will not be able to. Contract’s state is sandboxed and contained in the contract itself.
On the other hand - we are building nativie tokens. Those will be quite different from contract’s state one - you could pay your transaction fees, oracle fees and etc. with them. That is if the miner/oracle operator agrees using those as a valid payment method. You can surely transfer those to a state channel and use them to inside contracts there. This is to be implemented post mainnet.
It should really depend on the use case. Smart contracts in channels can refer to on-chain objects in their logic. That would mean that if an OracleA posts the weather in London every day on-chain, Alice and Bob can use this oracle response in their off-chain state channel contracts. For example - they can bet on what the weather will be like in 5 days according to OracleA.
Having oracles inside channels is not impossible but it will result in much more complex channel’s protocol (esp. in the negative case when Alice wants to use the blockchain as an arbiter) while it will provide dubious benefits. Channel privacy will be impacted, but if you want to use a consesus of oracles (you query 3 oracles and wait for at least 2 of those having the same response) - you want to have them all in your channel. Supposedly you’d have a couple of contracts inside a channel, that will require distinct oracles to be included as well. This impacts both privacy and the amount of data that goes through the network and does not scale well. At the moment we stick to using on-chain oracles.
thanks for answering my questions. just one more question to get more information about the possibilities and limits of state channels and smart contracts within them:
I just think about how it could be possible to create assets in form of standardized tokens like the ERC-20 on Ethereum and build business logic around them within state channels that could also include changing balance/ownership of a certain asset.
Hi @marco.chain,
It really depends on what you want to do 
Now we enter another realm but you could have much more complex smart contracts than just transferring of coins/tokens. You can play chess for example, you have all the infrastructure for that.
Channels by themselves are sort of a side chain. It is just that they are limited to two participants. You can create stuff off-chain, incuding artifacts and tokens. It is just that those will not make it on-chain in that form yet
Imagine the following example:
Alice and Bob have a channel. Total channel balance is 100 AE. At no point of time more AE can be withdrawn from the channel. This is enforced on-chain. The channel state is the following
AE and 10 myGameTokenAE and 15 myGameTokenAE for myGameToken at some rate (currently 1 AE = 2 myGameToken). It changes AE for myGameToken and vice versa. The contract has a balance of 50 AEmyGameToken as currency.At any point of time both Alice and Bob can cash out and exchange their myGameToken for AE but yet the fixed rate in the contract might still change.
You can also create some other asset (lovelyGameBooster) that can be sold for myGameToken/earned/gained in some other contract and having this lovelyGameBooster can impact contract calls for Game2 for example. All of this is possible with our current state.
What is not yet possible is to take out your lovelyGameBooster out of the channel and put it in another channel. So no assets transfer neither between channels, nor on-chain.
So again a few question in response to your answer:
myGameToken) within state-channels right?
myGameToken a specific token following a standard that can be used in within the core-implementation of state channels?I think I still don’t totally understand how the process in detail looks like. curious about your answer! 
Hi @marco.chain,
Yes Even though this is not part of the protocol, this could easily be done with the current implementation. The most important thing is that contracts are really cheap, fast and easy to create inside a state channel.
This would take advantange on various different mechanincs mostly contracts calling other contracts. Probably the most trivial implementation would be a contract that keeps the balances of Alice and Bob for various tokens that had been invented inside the channel (closely resembling ERC-20 contract). So in order for Alice to use myGameToken in gameContract1 - she makes a call to balanceHolderContract (the contract that has some myGameTokens that she can use). While calling balanceHolderContract, she provides the address of gameContract1, its function to be called, params and etc. balanceHolderContract moves some myGameTokens in its state from Alice’s balance to gameContract1 or whatever address that make sense in this case.
Probably the most important thing would be to build contracts keeping in mind that at any time both Alice and Bob can resolve all contracts via the solo closing sequence. Or not, actually. Some contracts might be unilaterally unresolvable by purpose (and potentially burn the tokens they hold in a solo close). This really depends on the use case.
Let’s have Alice and Bob. They have a state channel. Alice wants to play tic-tac-toe with Bob. Alice proposes Bob that they both add a certain contract inside the state channel off-chain state.
In our current implementation Alice provides the contract’s code. There is no check if this contract is present on-chain or not. It is up to Alice and Bob what contract they want to use. We will make it possible to drag contracts that are present on-chain to the channel’s off-chain state but this will be post main net. This will be just a shorthand for getting the contract’s code and will not impact the protocol. On-chain contracts have a mechanic for reference counting the on-chain contracts that refer to them but there is no way of doing this for off-chain contracts. It would be nasty if the contract you’re refering on-chain disappears . Since having contracts off-chain is so cheap - off-chain state will copy those in the channel’s state, so participants are safe if the on-chain contract is closed.
On-chain and off-chain contracts solve different use cases. While on-chain ones are public, it is much more cheaper to use the off-chain ones and you can take advantage of a soft-real time interaction. I’d imagine on-chain and off-chain contracts being radically different.
Both of them execute the contract call locally. This must be deterministic. Then they compare output and results - they must match. This is how we keep state channels trustless.
If there is any dispute, anyone of the participants can bring the contract and its call on-chain. This is the forcing of progress. Then it is the miners who execute the contract.
State channels updates are 2 phased ones: Alice proposes and update, Bob agrees to it. Agreement is achieved by the update being co-signed.
Each update consists of some change being applied to the channel’s state and the root hash of the new state hash (with the change being applied). If the other party is happy - co-signs the message and returns it back. Then the proposed state is the currently latest one.
It is worth mentioning that at no point the full state is being sent between them - each party persists its own version of the state locally and applies upcoming changes to it. The proof that they both share the same state is the root hash of the MPT produced by all MPTs in the channel off-chain state (we call this state_hash).
You can read the full state channels description here. The various on-chain transactions that are part of the protocol are in ON-CHAIN.md. We provide FSM that connects to other channels clients via a noise protocol. Its messages are described in the OFF-CHAIN.md. It would be really helpful if you want to build a noise protocol client of your own. We also provide a WebSocket client (that uses the FSM and noise) which would probably be the easiest way to use channels. You can read about it here.
thanks again for the detailed answer!
just to be sure that I understood you correctly when talking about usage of custom tokens within state channels another few questions:
Æternity-token right?myGameToken would be created and thus only exist within the state channel between two parties right?
so the very abstract procedure looks like this:
Hi @marco.chain,
Another set of great questions!
Yes. Each channel has an amount of AE tokens - this is exactly the amount that had been put in the channel via the create transaction and later modified by deposits and withdrawals. At no point more AE tokens can be withdrawn than this total channel amount.
Yes, indeed - to both questions. For this one would need native tokens. Those will be implemented post main net.
Yes, in a very abstract level - yes. That is if by change balance in 2. you mean off-chain balance.
Both parties commit tokens to a channel when it is being opened. This is the total_amount of the channel this can change but under no circumstances can go bellow a certain treshold.
After the channel is opened, both parties can make off-chain and on-chain updates. On-chain ones are transactions - deposit/withdrawal/snapshot/force_progress. Off-chain are off-chain token transfers, contract creation and calls.
At any point they can agree on closing the channel via a mutual close transaction. If they don’t reach an agreement or one of the parties is missing - the other can initiate a solo closing sequence.
To make things even more robust - we have implemnted on on-chain level delegates - third parties that can protect your interest while you’re offline. Currently they can only post a slash but they will be allowed to post a snapshot as well.
thanks again @dimitar.chain!
you really helped me understanding the concepts better. but again I have a few questions for you:
Hi @marco.chain,
I am happy to help you.
Our main focus for at least the past few months had been the mainnet. We dedicate all our efforts in that direction, polishing evey detail we could in order to make the protocol lighter, faster and more scalable. We are eager to deliver the native tokens but since those are pushed post mainnet, we are not really working on them at the moment. We had discussed them in private talks and we have a general idea what they shall do but I am not aware them being specified anywhere. So once created, native tokens shall be used the exact same way one would AE tokens: not only in channels but also pay miners fees, pay oracle operators and etc. Of course it would be up to miners if they accept this amount of this native currency as a payment method Same goes with oracle operators, name service registering and etc.
Keep in mind none of this is set in stone and is subject to change.
This is a great question! We are doing this (possibly following Perun’s approach with virtual channels). Since this is to be done post main net, we haven’t dedicated much time to this either. The important thing is that we will implement the infrastructure for this.
Hi,where can i find example code on State channels being used as payment channels?
Thanks
The question is related to a possibility of introducing a burning rate for tx fees (payed in AE tokens or native tokens).
What is the state of native tokens? I am especially interested in if it would be possible to pay for tx fees with native tokens. In this scenario miners will accept transaction fees in native token. Additionally they will receive coinbase reward in AE tokens. When there will be burning rate implemented, they will need to burn AE tokens that will be equal to the value of [tx fee * burning rate]. Probably they will need to use Oracles to determine how much AE tokens to burn based on the market value of native token.
I wonder how such transactions would looks like technically. Will they be complicated and bigger than standard transactions?
The conversion rate of native token to AE token is not necessary if there is no burning rate as miners can calculate the minimum tx fee to accept individually. But it would be necessary if there will be a burning rate implemented because there should be a deterministic mechanism to calculate how much AE tokens to burn and all the other nodes will verify it, so we would need such a conversion rate provided by Oracles. The price feed might be updated once a day. Or I can imagine we can have a transient price feed that will not be permanently stored in a blockchain, but only available for a week or 24 hours. As I can understand the Oracle responses might also be pruned from the blockchain after TTL.
What do you think about this idea. Is it technically viable. No other blockchain have such mechanism implemented. The trend is to go towards PoS and staking. In my opinion implementing a burning rate will be a next trend and Aeternity has very good position to have it first as all the past ideas (Oracles, native tokens) naturally suits to this scenario.
P.S. Personally I think cryptos will become a platform to operate contracts mostly using tokens backed by some assets, equities or even better synthetics (like DAI/SAI, etc.). In this scenario tokens market cap combined will be much bigger than pure cryptos market cap unless there will be a burning rate implemented.
P.S.2. Ripple (XRP) has such a burning rate implemented:
Every transaction must specify how much XRP to destroy to pay the transaction cost.
Beneficiaries of the Transaction Cost
The transaction cost is not paid to any party: the XRP is irrevocably destroyed. Since no new XRP can ever be created, this makes XRP more scarce and benefits all holders of XRP by making XRP more valuable.