Strictly speaking, this is optional. It is also possible though not easy to swap out MongoDB with another database.
I don’t think the exact architecture was communicated in detail just yet, (and I’d really love to hear more on it!) but I don’t see how someone else running an “API Server”, (and like I said, I don’t know what exactly it does) makes it possible for me not having to trust them, when using that API. Could you elaborate on that ?
Even if those API servers act as load balancers, distributing calls to different blockchain nodes, for all I know it’s not asking any node and just making stuff up. Are you doing something akin to TLSNotary maybe (cuz that would be really cool)?
What is this database for? Storing blockchain data only ?
Or our Dapps could CRUD on it?
Is it too hard to enhance mosaics with more features like: vesting, custom expiring dates, a memory region specific for storing data, …?
@jabo38 supporting your argument
ConsenSys claims it will soon start charging for Infura, another tool that facilitates access to Ethereum.
Thank you for that link!
It doesn’t answer my question regarding @jabo38 statement about trusting nodes (if it does I’m not seeing it) but it does bring up other questions.
It states about the P2P component:
The P2P nodes form the backbone of the blockchain. The role of the node is to verify transactions and blocks, run the consensus algorithm, create new blocks, and propagate the changes through the network.
Then it states about the API component:
Additionally, this layer verifies blocks and transactions.
So which is it ?
It further states about the API Component:
Catapult API collects cosignatures. Aggregated bonded transactions are pushed to P2P nodes once they are complete.
Does this mean that all of the transactions of an aggragated bonded transaction have to be published via the same node ?
So every node (the catapult equivalent to NIS) will consist of an API component and a P2P comonent and can, as a seperate service, also run a REST API endpoint. Is that correct ?
I think It will be confusing if people are supposed to be using the REST component, when there’s another component, literally called API.
Funny, an article just came out about this. https://www.coindesk.com/the-race-is-on-to-replace-ethereums-most-centralized-layer
Had Ehereum been designed with a MongoDB like NEM is, I seriously doubt this would have happened.
The P2P nodes are the ones that verify transactions and blocks the first time, which is arguably the most important time.
I’m assuming the API server is checking again to make sure it isn’t being lied to.
But I know for a fact, a light client can do this. Yes, a light client can even verify cryptographically that things are on the up and up. This is through a Merkle Tree and cryptographically is the same thing as having a full chain on the light client, except for it is a very light chain with a majority of info that is irrelevant to that wallet stripped out.
Let’s forget about it…we’ll see when (if?) everything is documented and released.
I think NEM shouldn’t try to compete with Ethereum on that topic. NEM has positioned itself as easy to use blockchain with a standardized set of functionalities.
if NEM really wants to provide as much flexibility as possible I think we should more think about what interesting features are being built on top of Ethereum and if they are useful NEM could pick up certain standards and functionalities and implement them into the core.
but I think it is extreme difficult to adapt certain standards/functionalities so that it makes sense and that combination of different features can be used within a “standardized business logic”
@gimer I for example would like to have a feature to be able to freeze my holdings (XEM and other mosaics) for a certain period of time (HODL ). at the same time the frozen funds should still be available for use, e.g. to participate in votings. only transfer of ownership should be blocked.
maybe there are also some projects that would like to implemented some kind of staking mechanism for their mosaics/assets.
is it possible that such a feature will be integrated into catapult?
I think NEM don’t have EVM and should not have EVM either.
Here are reasons.
- NEM should be a leader not a follower. We are an API driven blockchain which don’t support EVM. So we don’t have all those weakness which EVM has. We need wo focus on our own strength, make us the best API driven blockchain. Not to fight other’s strength with our weakness.
2.EVM is actually an terrible idea.
TCP/IP has 4 layers and OSI model has 7 layers.
Ideal blockchain solution should never consist of only 1 layer. Trying to solve everything with EVM is a really impossible solution.
On the other hand, NEM have 3 layers: blockchain layer（NEM core）,API layer and SDK layer.
This is what the real business involving blockchain will need.
3.Plug-in can be a much better solution than EVM.
If there’s really a need for on-chain smart contract. With plug-in one can customize his own transaction type on private chain. And if the transaction type customized is popular, it might be insert into public chain as well.
This is a much safer and more efficient way than using EVM.
Some thoughts from Steve Li, NEM China
I think the ethereum smart contracts excel at doing decentralized projects, the fact that an agreement within multiple parts can be achieved being inmutable and tamperproof is a clever solution.
In a case where the agreement is between two parts, under the assumption that an enterprise is not a dao, NEM could be a good solution, so that the contracts are defined by the two parts, and can be placed off-chain and changed/implemented in a continuos development pattern.
Ethereum is not capable of that agile change management, but even in DAO projects, the smart contracts can be upgraded using Factories, and “deactivated” with “suicide” methods in Solidity, so that you change to a new version and cancel the older one.
Of course all of this will cost you “money” in gas/ether.
You must be very “cost conscious” when programming in solidity/ethereum, because a bad design could cost you a fortune. That is not a problem with NEM smart contracts.
So as I said before NEM is not capable for all that dao things, but I think nor DAOs nor digital cash is the main purpose of NEM technology.
I think that the main competitor will be Hyperledger in that enterprise scenario, so that maybe would be smart to partner with some IT giant such Hewlett Packard, Microsoft, Oracle, etc…
The money in blockchain tech is growing in B2B, not in B2C, so I don’t think Ethereum is the first choice in B2B projects actually.
Sometimes having the option to run an application automatically for unlimited time
after the developer is gone would be a nice feature.
This way some computation logic will not depend on a central server or entity like it is now.
If this could be achieved with kind of plugin system would be nice.
For example plugin system that let any user to install the application and get rewards for
running it so to avoid that every node needs to validate the same computation.
This could open an “appstore” like market where independent NEM developers could deploy their apps and users interested to run it could install it and get rewarded.
This could be even beneficial for those users that have less then 10000 xem and can’t harvest
as they could generate some income anyway.
If this plugin system gets implemented it should run on some kind of sandbox
with limited file system / system accessibility that can be configured from the config file.
I’m just throwing ideas don’t know if this would be even possible or really needed option.
Anyway I like this thread is a nice discussion thread
I hope it can bring some improvements!
This ability is a great ability and I’m happy to see them get that, but then the question remains that what happens if the contract maker’s private key is exposed and the hack suicides and deactivates the whole thing?
To me the beautiful idea about Ethereum is just what freigeist said, that sometimes having the option to run a program that will last forever is pretty cool. But if the platform sucks and it is so hard to make that program that you have to include a catch that allows you to edit it in the future, it kind of defeats the purpose. Now you always have to trust the dev to 1) always update it correctly, and 2) hope his security is so high he isn’t hacked. Dam… that is starting to sound like the old system that blockchain was supposed to fix in the first place.
This solution works on other blockchains (time locks) and I feel it will be easy to implement on current catpult version, just as a timelock with specified amount of funds. They will still work as a stake, and you could leave yourself like 10 XEMs for making transactions, but most of the funds would be on the specific time lock.
I think it is already done and even in the SDK. https://nemtech.github.io/concepts/cross-chain-swaps.html#secret-lock-transaction
Now you are talking about security. I don’t think NEM excels here.
Keeping safe the private key is a common issue in all blockchains, as far as I know.
Everyone is singing the mantra “be your own bank”, but are you adopting the same security procedures that enforces a typical bank?
Moreover, to protect a private key, you encode it with a text password?
The password, a technology discovered in the 1960’s?
Really? All that tamperproof, consensus algo, distributed ledger, PoW, PoS,… and we are protecting all this with “123456” () or “qwerty”?
Using a word (or words) that can be forgotten, lost, or easily guessed (there is always dumb people…) ?
Do you save the private key in a usb stick and put in on a drawer in your room? Quite better but not best.
Where is all that biometric authentication? Why is not used?
Where is the fingerprint reader, or iris scanner setup in every wallet?
Ultimately the weakest point of failure is the owner of the private key, and how the owner protects it.
There is no time-lock though which unfortunately removes some nice possibilities, lightning channels among them.
No. Only you have your private-key and nobody can access your funds without your permission. That’s a hell of a lot better than a typical bank and the whole point of that mantra. How you keep your private-key safe is up to you and there are various options ranging from “here take my money” level to “crazy paranoid” level.
What are you even talking about here ?
Actually the mobile wallets do support fingerprint scanning, should your phone support it. Again, how you store your priv-key is up to you. If you want to encrypt it with your dna signature you can do that, just need to build it.
Using biometric data is also not inherently more secure. Quite the opposite, considering consumer-level hardware has been “hacked” time and again. Using a 100 char password is way more secure. It is more cumbersome but you’re talking about security, not convenience.
Lastly, do you know of any project that is doing a better job than nem in that regard ?
My response was about:
He talked about personal security (securing priv.key), and my point was to show that is not a NEM feature vs Ethereum, it is common issue in all blockchains.
That was my point. That many people want to be a bank, but do not implement security.
Managing your own assets involves responsability and work, if you don’t want that, better save it in a typical bank and forget about blockchain (as a digital cash platform).
My point was to emphasize that we are using an old technology to encrypt wallets (or private keys), such as using a text password.
The wallet interface should be more “mainstream”, easier,…let us face it, it is made for geeks.
How people login in a wallet? Entering a text password.
No, use something you own (beacon), plus something you remember (password), plus something you are (biometric).
Of course here I am talking about protecting very valuable personal assets, let us say 100k-200k$, 500k$?
if you have hundred bucks use a simple password and forget about it.