I hope this doesn’t sound too dumb to ask for the sake of my knowledge, why doesn’t NEM have its own virtual machine like Ethereum does for its smart contracts?
- NEM has no smart contracts like in Ethereum
- It’s no need to have own programming language. NEM use HTTP API. It’s easy to integrate in each application.
2 Likes
Hi Guys,
Sorry i’m new to nem. Do you guys know how to configure NIS using proxy server with authentication?
Thanks.
What would you develop in such NEM virtual machine?
- ERC20? Already have Mosaic.
- Multisign contract? Already have multi sign NEM accounts.
- Storage? Better use IPFS or in the future ProximaX
- Please add your own…
1 Like
Any and all contracts that aren’t multi-sig or assets and there’s plenty of those. Anytime you want to put actual business logic on the chain (e.g. for resiliency or transparancy) you’re fresh outta luck with nem.
Actually the complexity of some of the things you can do on NEM is way better than what you can do on Ethereum. Don’t get me wrong, in Ethereum you can in theory do “anything” but the reality on the ground is that most contracts are really what was mentioned above which are multisig and ERC20.
But lets say you want to do some really advanced stuff, like name domains. NEM has a naming service that came at launch (which was before Ethereum launched) and worked great where as the ENS has stumbled and is still in “alpha”.
Or what about levies on txs for your ERC20, good luck, most complicated contracts like that on Ethereum sooner or later get hacked or blow up.
And then we have Voting, Done. And we have the most advance file notarization, done. These go back years.
And if you can do very complicated things for business logic on Ethereum, why is there no ETC <-> ETH swap contract that is trustless? But on NEM in between Catapult to Catapult chain, it is already in the SDK. Super easy.
Then there is something called “aggregating transactions” where you can do this on Catapult, and literally, no EVM wiill ever be able to do that business logic, but on NEM… done.
I can go on and on. The truth is, there are so many cool things you can do on NEM, or have been done for a long time on NEM, that it is really impressive for somebody who deep dives into reality on the ground verses promise. And yes, about 5% of the time, I do indeed find a project that you can’t do on NEM but would have to use Ethereum. But 95% of the time it is easier and cheaper to build on NEM. And of those 5%, we end up with contracts like the DAO, or Bankor, or other contracts on Ethereum that blew up.
4 Likes
You have a point with most of what you say but…
Voting on nem is sending a 0 XEM tx to some predefined account. It’s not like that’s special. Come on 
Could do that on any chain, dag or whatever.
I’d argue that it’s very much possible to make tx depend on each other in a smart contract environment. Even if you have to deploy a new contract for each of those, it is possible. Actually, devlopses is afaik doing that for cacheout (I believe it runs on Tendermint). Everytime a user asks a question a new smart contract is deployed. People think of smart contracts as these big bulky things to be deployed once and then used until they break but you can use them in way more versatile and “lean” ways. Efficiency is of course a seperate concern there.
(While we’re at it, I think that multi-sig will become less user-friendly in catapult due to it being an aggregated tx that requries a bond but that’s besides the point, just wanted to mention it.)
I’d never suggest I know better what’s happening on the ground than you do, but the reality is that there are still projects who went for ETH instead of nem and there’s some reason for it. It’s probably not always technical, hell maybe it’s alsmost never technical, but it exsits and touting nem as superior isn’t going to help it.
While we’re at it. I think time locks would be a worthy introduction for public catapult. It would make a few more use-cases possible, including lightning channels.
Recently I was asking how to create vesting mosaics, or expiring mosaics for a custom date, or self destructing mosaics like solidity smart contracts, actually there is a lot of features that could be added.
Of course all this could be implemented offchain, but then what would be the point ? Mosaic paradigm is so powerful, that should be enhanced even more.
please give an example, where that happened in ETH and didn’t end up in complete failure.
https://www.stateofthedapps.com/rankings/platform/ethereum
No way all of those are desasters and while I haven’t looked at them closely, I also find it hard to believe that all of those are only assets or mult-sig (allthough I’m sure many are).
I’m not even saying nem needs full-on smart contracts or even that something needs to change. I’m just saying there’s a reason people build on ETH and not NEM. There’s gonna have to be a better narrative than “we don’t need them, they’re buggy”. ETH has it’s advantages and they should imho be recognized rather than dismissed if nem wants to be taken seriously.
Also nem’s hardcoded smart contracts can have bugs too. I know you guys are good but you’re still people. I seem to remember every multi-sig address getting 1 XEM from Bloody beacuse of some issue ?
If a smart contracts is broken, it’s that contract (and potentially other contracts that use it). If there’s a bug in nem’s multi-sig absolutely everyone is affected.
It may very well be that the world will dismiss smart contracts altogether but until then let’s have a better answer than “they’re buggy anyways” ?
One problem with Ethereum smart contracts as far as I know is version management.
A contract is engraved in stone. You cannot fix the code.
Contract addressing is messy. Namespaces are an elegant solution.
You must use “oracles” to access the offchain world, so adding 3rd parties, more ether you must pay.
Storage is expensive in ethereum. In a mosaic you have 512 bytes for 10 XEM/year.
Also nem’s hardcoded smart contracts can have bugs too. I know you guys are good but you’re still people. I seem to remember every multi-sig address getting 1 XEM from Bloody beacuse of some issue ?
If a smart contracts is broken, it’s that contract (and potentially other contracts that use it). If there’s a bug in nem’s multi-sig absolutely everyone is affected.
Sure it is but in ethereum every contract could be buggy, as everyone is implementing the same again & again. In NEM maybe one fix could fix them all (depending on the issue of course).
We all know the escalability problems in Ethereum, too.
But… It would be awesome to have some executable mosaics in the future…I am working on something cool, time will tell.
Namespaces aren’t addressing anything but mosaics though. Which is better than nothing of course, I just think that if we can refer to accounts via addresses it’s not a huge leap to refer to contracts in a similar manner. Also names are a way for scammers to create similar looking mosaics which is of course also a problem with addresses but users are way more likely to verify 0x5s4df65as4d6a456s4d6a5s4d65 than totallegit::gold. Not an important point I just thought it was worth pointing out.
That is of course true but in xem you basically have nothing but oracles. The oracles even run the logic (business logic that is)m Which again is fine, I just don’t think it’s an inherent weakness in smart contracts. In fact there are some awesome things about those oracles like you’re able to prove/verify cryptographicaly that an oracle answered your question with certain data at a certain point (if you want read https://blog.oraclize.it/understanding-oracles-99055c9c9f7b and https://tlsnotary.org/). Without smart contracts and oracles it’s all hidden away and the user has to trust the people running the code.
I mostly agree with everyone’s points about smart contracts vs nem’s contracts (we should find a catchy name btw.), I just dislike the general attitude of nem being superior in every way and that that’s how it should be marketed.
I hope you DO realize, most of the “apps” listed there, doesn’t really use EVM in any way, right?
(I would dare to say all, but I don’t have time to go through whole list…)
Yeah, since everything is already implemented/better in NEM than ETH there must be something what ETH offers better, something what motivates people to put money into it, or to develop number of secondary apps on eth block chain, something what sparked interest of GS and other financial institutions, countries like Russia. There must be that something there which is outperforming nem.
I got the same problem, would have to go through the whole list figuring out what all of them are doing and whether it’s possible with nem or not. All these discussions are very theoretical
Maybe ethereum is used mainly for creating ICOs.
NEM is already in crypto group which is grasping for survival. Many factors are contributing to this situation but human ignorance, greed and arrogance are driving forces of NEMs current misfortune.
nem is doing a lot better than a ton of projects in the top 30. nem’s biggest problem is the state the foundation is in.
I love this conversation.
There are things that Ethereum does do better. Like the DAO contract (had it not broken, maybe a bad example) or the Bankor contract, or anything with emission rates can’t be done on NEM right now. That is the main problem I run into when attending meetups and conferences and when I tell people they have to use Ethereum. Even those can and have been handled centrally on NEM but it isn’t trustless and isn’t a beautiful solution in the way I would like although it very well might be safer, time will tell.
Generally speaking, I really do believe for at least 90% of projects, it is faster, safer, and easier to build on NEM, but it brings more name recognition and better fund raising options to build on Ethereum more than 99% of the time.
To Gimre’s point, I can name some projects building on NEM, but the fact that we are only giving anecdotal evidence of a list means that there is no one shining example of a great app on Ethereum with lots of users that has been successful and actually did need the EVM. At least not one to the point that people can rattle it off the top of their head.
I know it would seem like that, and I understand why you say that, and yet… almost no other chain has done it. One might wonder why…
I think it is because, yes, it is just sending an empty tx, but and I found this out the hard way when designing and building the voting protocol, sending the transaction was the easy part. Actually the hard part of a voting app believe it or not is counting the votes. And I know that sounds crazy, but yes, that is the hard part. Why it became possible to do voting in NEM is we had an API and schema to write the polls and information in the blockchain in a way so that it can be interpreted in a decentralized manner, but two, that we had the APIs so that any light client can verify those results independently. I actually had designed even more advanced options like “voting by stake” and “delegated vote contracts” but the APIs just weren’t there to support counting those yet. I’m very happy to say that when Catapult comes though, all those APIs will be there as it is a major upgrade and the voting system too will get a big upgrade.
Basically getting all those votes on chain is actually the easy part, it is getting all that information off the chain and read and interpreted easily in a way that anybody can verify which is the hard part. Any other system is probably going to have to build a centralized service that you will have to trust, where as we have the counting down to some javascript that anybody can inspect and audit. And that is thanks to NEM’s API. Actually, this is a BIG problem right now in Ethereum and why Consyns had to build Infura so Ethereum devs have APIs that are easy to build on for reading data, but now Infura is processing 10 billion queries a day. No kidding. That means all those queries and all those apps are relying on a centralized company to run and trust it.
I’m so happy that the NEM devs saw this coming years ago and built a MongoDB/API server on every NEM Catapult node. Now any dev doesn’t have to trust a centralized company for APIs to operate their app.
4 Likes