Where are smart contracts stored?


#1

Hey guys,

I was reading the whitepaper and I came across a question.

I am confused that the place where the smart contracts stay.

Is it like the ethereum and stored in the block?

(Then my question would be, in the whitepaper, ‘the block contents’ part, I didt see anything about it. Why?)

or

Is it stored in the state channel?

So, currently my thought is that the smart contracts are stored in the blockchain, and any body can call them.

It is like “drag” the smart contract into the state channel and execute it by the 2 nodes that needed.

so, overall, the smart contracts are stored globally, executed locally, and then the results are uploaded and stored globally. Am I right?


#2

Hey @waynee,

Sorry for the late response.

Your question has been forwarded to our dev team and they’ll get back to you as soon as possible.

Best regards,
The AE Team


#3

Hi, @waynee

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.

  1. 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.

  2. 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…)

Regards,
Dimitar Ivanov


#4

Thanks for the explanation @Dimitar.Ivanov. 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?


#5

Hi @databu,
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.


#6

Yes I’m aware of this, I should have been more precise: how do I get the byte code of a contract from the chain/channel?

Also how is one supposed to handle the case in this model where the contract was compiled with an earlier compiler version?


#7

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 :wink: )

The version is inside the contract itself so it is known which compiler is to be used to get the correct bytecode.


#8

I wanted to test this but currently have problems deploying a smart contract, see also my last post here: Æpps update: Smart Contract Development


#9

I will ping the guys developing https://contracts.aepps.com to check your problem in the other thread


#10

Hi! Great concept <3

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 :slight_smile:

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.


#11

Hi @Experientialist

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).


#12

Thank you for the reply!

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 :slight_smile: