Can anyone explain how smart contacts will work in NEM? Is it possible to store data in the block chain where a smart contract would operate on? If so what is the size limits of such data? Can data dynamically added and removed of a block chained smart contract? How NEM is planning to scale efficiently while allowing unlimited data of dynamic size to land on the block chain?
Everyone knows I’m not a dev, so this is just my opinion. When I think about it, I think it would be nice to have like 10 or so basic account controls that are available to all users at anytime as they are supported by NIS. These account controls and triggers can support privately hosted programs that carry the majority of the heavy heavy lifting, data, and computing. These off chain smart contracts are much lighter and more flexible off the chain and don’t bloat and could only act in conjunction with the chain’s support. This would mean these contracts would have the ability to unlock, lock, or carry out a limited range of tasks specified in their programs. It would also be nice for those that don’t want their contracts hosted privately to be able to access open sourced contracts hosted on an approved depository and and run and processed on a distributed computing platform. This would then take an additional small fee but the decentralized computing and and open source coded contracts could help to minimized trust issues.
At least that is how I imagine it. One thing is for sure to me. NEM had an amazing asset program in Namespaces and Mosaic. Now it needs a reputation market system and smart contracts and this will be a very well rounded system that can meet needs that no other blockchain is doing.
Also… Our multisg is in some ways our first NIS supported smart contract or account control in my opinion.
A first example of a smart contract with an account control is XEM Pay/Sign on multisig. At least that’s how I kind of see it.
That might sound weird but let me explain. Other multisignature accounts in Bitcoin are created and managed by wallets. In NEM there are little contracts on our chain explaining limits of multisig accounts. Quantum Mechanics utilized this account control and then wrote a program that acts of somebody makes a request they get money. Except this action is carried out by two programs on distributed computers.
It’s an example of NIS supporting special inputs for transactions. He then has programs that are distributed that work only when certain conditions are met to carry it out.
That’s why I have been saying, we can already do centralised smart contract in whatever language one chooses.Also, I am more inclined to believe that smart contracts are more likely to be centralised contracts anyway.
Faucet is a proof of rudimentary concept of a smart contract. You key in your address and we promise to send you the 100 XEM through our theft proof wallet, i.e., multisig account - automatically.
To be honest I don’t know too much about smart contracts , but here my thoughts on it:
Can a smart contract be fully decentralised without accepting some alternative to thrust?
The only kind of smart(?) contract I can think of is something like a delayed transaction that executes at a certain block height. All other things I can think of either requires consensus or an external source that has to be trusted. I may be completely off here ( if so, please educate me 
)
However , if there would be some sort of reputation system on the blockchain that can act as a substitute for thrust it would become a different ballgame!
If the reputation system is developed in a flexible yet secure way it may become the catalyst in a smart contract. Either by using the established reputation of the envolved parties or by using an independent intermediary with an established reputation. This is probably pretty vague but I’ll give an example:
I’ll give an example with the external party since that will probably be the most secure way. It can be seen as a form of escrow that can be used for smart contracts.
So assume I have a company who’s customer is another company that wants to use a bonus/malus system linked to some KPI’s. (e.g. if I deliver a service or product sooner than expected I receive an bonus but if I deliver late a penalty will be applicable)
Then you only need to find a party with an acceptable reputation to asses the KPI in a predetermined way. ( e.g. an audit or confirmation of the validity of some evidence)
Obviously this is just one example, the only limiting factor is imagination 
In any case, when a smart contract is issued the involved parties have to agree on a (trusted) input that will trigger the execution. This can be anything, but to prevent scamming and cheating a reputation system would create a lot of possibilities.
Again, if someone can point me to examples where this is dealt with in another way; I am really interested.
Smart contracts are Decentralized Apps. They should reside in the block chain and operate and execute over data stored on the block chain. For that the block chain should support data storage. You can extend these functionalities with trusted non block chained nodes. However, you should still support minimum functionalities on the block chain itself.
Perhaps side block chains are needed in order not to Jam the main block chain. This is the way Ethereum decided to go. I am not sure if thats how Ethereum works today but as far as I know this is their future plan. Using side block chains would give us the flexibility to add complex decentralized functionalities to NEM in the future whenever that is needed.
It would be hard to have smart contracts without turing complete programming language and a turing complete machine. In this case NEM nodes would run turing machines that are capable of storing and executing dynamic code “smart contract”. By then the possibilities are unlimited.
Without a turing complete machine the smart contract functionalities will be limited to the core features of NEM block chain and asset exchange. That would eliminate future decentralized application from fully operating on the NEM block chain. As external resources will be needed to support the dynamic logic that the NEM block chain can not handle. Relying on external resources will make Dapps “decentralized apps” operate in a centralized manner. Where the service can easily get disturbed and/or hacked. Which would make smart contracts less decentralized and less secure.
I am wondering if NEM has any future plan for adding a turing complete machine.
Hmmmm. I hadn’t considered side chains as a host of smart contracts. I’m of the opinion that side chains will someday be fairly easy on NEM. I think NEM’s PoI being a variation of PoS and the fact their are so many APIs that either the support of a couple more transaction types, it should be possible. Might also need corruption from supernodes too.
Makoto mentioned in the interview that the ultimate plain for NEM development is to have multiple simple titles/tiles that when connected together can build great things such as a decentralized internet. He namely mentioned titles/tiles such as bandwidth, storage and decentralized CPUs. I am wondering if there is any current plan/design for such amazing features. Perhaps all will fall into smart contracts in one way or another. I would appreciate it if Makoto can clarify the future design of these functionalities. Will side block chains be considered to form side decentralized resources? I think that would be the best way for building trust in and out of NEM main network/blockchain.
I’m not so sure about that. I mean of course you know more about the current plans than I do but having multiple chains will imho never be “fairly easy”. Compared to coming up with a theory of unification? - Sure. In general? - I don’t think so
There has been no discussion about it. Makoto isn’t a big fan of sidechains, at least in the near term. I’m probably the biggest supporter of it. I think Gimre once said it wouldn’t happen too if I remember correctly.
Maybe I never really understood it, but for me side chains have always been the same thing as clusters in the end. One big chain with clusters or multiple chains with connection points. Same result, right? Both is a way to increase the efficiency for decentralized blockchain platforms (which is a serious problem).
Yes it is all about clustering. For example if NEM will have multiple smart contracts in the future where each will introduce a specific functionality such as bandwidth, storage, CPU, … handling all requests/transactions in and out of these smart contracts in one single block chain would result in having one huge block chain that would get extremely heavy in no time.
On the other hand clustering using side block chains would divide the block chaining activities into multiple block chains where all would be connected in a way or another to the main block chain or to one another away from the main block chain. This way users whom are not interested in specific smart contract such as bandwidth they would easily set their nodes not to support that specific smart contract to keep their node server lighter. Where users interested in supporting a specific smart contract such as CPU, would run nodes that only support CPU.
Clustering in such manner is something that we have to do anyways. Using side block chains for smart contracts would help regulating and trusting external resources rather than having external resources totally unmanaged, or creating a bottle neck problem by managing all things through the main block chain.
It would be nice if the amount of fees that somebody pays for a transaction decides how deep that transaction is added to the blockchain.
High fee -> main chain, EVERY node validates it.
Low fee -> just very specific nodes validate it.
And something between.
is something like that possible from a technical / code point of view?
Theoretically, sure. You would need some side chains, different type of nodes (full, light, and some in between), define which node type validates which side chain(s) and a threshold which defines which fee is needed to add a TX to a specific side chain (or even the main chain).
Guys, please correct me if I am wrong: It seems that Mijin will operate in a side chain manner. Where most of the TXs will be processed in a side chain “aka private chains”, while some of which will have to go public in the main chain for syncing purposes?