That’s a great question, indeed. It might not be well described in the whitepaper so let me clarify: we have two different types of smart contracts.
Public smart contracts (we call them just smart contracts) - those are part of the block chain. They are created and called with transactions, once those are included in blocks. Those smart channels are persisted on-chain and their execution and content are visible to all.
Smart contracts in state channels - those are part of the state of the state channel. Once both parties agree upon adding a new smart contract to a channel - it becomes part of its state. They could refer to a contract that already exists on-chain or rather use their own private smart contract. Situation is similar to contract calls - if both parties agree for a call - the smart contract’s call is executed by both participants locally and updates the state channel’s internal state. If one party decides not to cooperate - the other could unilaterally force a smart contract’s progress on-chain. This would require the contract to be posted on-chain and the call being executed by a miner (in a similar way of 1.). This would expose some of the smart contract’s internal state on-chain.
One big difference between those two would be that there is no gas cost for state channel’s smart contracts (unless one has to force progress on-chain…)
Thanks for the explanation @dimitar.chain. I have a somewhat related question: is there an API function to retrieve the smart contract code from the chain or from a state channel (that the node is part of)? Or otherwise, how are clients supposed to verify that a deployed contract is really the same as the one whose source code one might have been shown?
Hi @doktorbastian.chain,
The logic is the other way around: provided the code, one can inspect it and decide if one likes it or not. Then a participant in a channel can compile it locally to ensure that what one had been offered is indeed the same contract - if the bytecode of the offered contract is the same as the expected one - it is the same contract.
Contract compilation is deterministic so it is really easy to prove if someone is being honest or not.
Getting the code from the chain is pretty straighforward: there is an HTTP endpoint for this - /contracts/{pubkey}/code. This will get you the code for a contract that is deployed on-chain.
Off-chain it is not that pipelined as this is not part of the protocol itself. Users are expected to have a wallet that is keeping the off-chain state for them and provides means of inspecting it (hint: we have a team working on this )
The version is inside the contract itself so it is known which compiler is to be used to get the correct bytecode.
Erik connected me with this project. I’m studying how it works and I’m wondering about this point too.
Logically it makes sense that some info is processed on chain, like we are committing/escrowing n coins in a side chain / state channel (with non disclosed private details). But the contract details remain private and off chain. Great for privacy, and great for keeping on chain data super lite and fast. Understood.
Next is a special wallet and/or VM? to locally handle side chain transactions, using a merkle tree for data, keeping mainchain free of traffic. Sweet
But where is that merkle tree data and originating private contract stored? How is it preserved/restored if things go wrong? Could it be via IPFS? or some other decentralised and resilient storage system? Surely it’s not just 2 local copies on each other’s smartphones?
I tried finding the answer in documentation and videos, but couldn’t find it yet.
It is a participant’s responsibility to keep the off-chain state. This is outside of the scope of both the on-chain and off-chain protocols. Our implementation of the off-chain protocol keeps it locally on the node and provides/will provide access to the whole MPT so client can persist it whenever one sees fit. Probably this would depend on the amount of data and the rate of updates. Probably if one does not have many updates flying around and keeps the state reasonably low, one could use IPFS.
Then come the delegates. You can provide the latest co-signed state (consisting of root state hash and round) to a delegate to slash a closing state.
I believe some infrastructure for distributing state between a couple of storages and/or delegates will be handy. Currently we don’t provide it out of the box (but we could easily do so, some time after main net).
Ok… given Murphy’s law, if something can go wrong, it will! So building a solution for distributed storage, to provide the ability to restore a lost state, will really help mass adoption I guess. I can easily imagine the same kind of panicked cries for help much like “I lost my Private Key and didn’t have a back up”… self responsibility is a bitch sometimes. Anything that can make the process smoother for Mums and Dads will be appreciated.
Looking forward to following your progress, and will probably represent you in Australia if Erik is okay with that
)