Hello all! It’s been a while, since the last 101, but I figured I might as well start it up again with this cool and simple topic. As always, the goal of this is to explain certain Catapult terms/features in a simple, easy-to-digest way.

As you all know, the bison update has been released to Catapult. With it brought Account Properties, Merkle State Trees, and the Cache State. However, one aspect of Catapult got my curiosity sparked:

Are there/will be any light nodes in Catapult?

Luckily, we have great core devs that answer our questions - thanks @gimer for the info on this

What is a light node?

First of all, let’s define a light node. In our case, a light node is a node that can verify block headers and interact with the network, as well as harvest (equivalent of mining or staking in NEM) without having to download the whole chain. Merkle state trees aid in this entire process, enabling for the fast and secure read of data coming from Catapult nodes.

However, this exact functionality will only be possible with snapshotting, which isn’t implemented in NEM2 just yet, and isn’t foreseen to be implemented for the next couple of milestones.

Wait, there will be no light nodes?

Well - not quite yet. As long as we do not have snapshotting functionality for light nodes, we will not be able operate them in the way that we know (acting as a full node without hosting the entire chain). However, there is another concept that will be possible in the cow update. Introducing, light clients!

Concept of Light Clients

Light clients are client-side applications that allow the user to verify block headers and transaction statements. With the upcoming cow update for Catapult, wallets, for example, will be able to utilize this functionality to further verify information coming from nodes in a secure (and speedy) way. It’s possible that some of the sig efforts will implement this when the time comes. Think of light clients like light nodes, the difference being they only deal with the verification of information (like block headers or transaction statements) coming from a node on the blockchain. They do not harvest, or possess other capabilities that a full node (or even a light node, in the future) has. It is important to differentiate these light clients from light nodes. As shown above, they are functionally different from each other.

I hope to update this article as progress is made, since the majority of this is WIP. That is part of the reason why there aren’t too many details. If anyone has anything to add, or if I got something incorrect, please let me know!

I see you mention here block headers validation.
I found an article where they mention there is an flaw in POS coins.
They called this “fake stake attack”. I’m not expert in this things so I do not understand majority of things explained there but this could be interesting read for the developers@gimer, @BloodyRookie, @Jaguar0625

Proof of Stake can be implemented for UTXO-based blockchains. Those are the ones at risk for this type of attack.

NEM is account based (similar to ETH) and therefore not at risk with this particular attack scheme.

From your link above :

PoS is to ensure that each stakeholder’s chance of mining the next block is proportional to the number of coins they control. To achieve this, in chain-based PoS the hash depends on not just the block header, but also the quantity of coins included in a special “coinstake” transaction inserted in the block by the stakeholder.

This does not affect NEM because with NEM, the importance of an account (the “coinstake” so to say) is calculated each 360 blocks, not using this type of mechanism involving disk and RAM. (RAM is still needed, but not used in the same fashion.)

Are there more details on those ? I can only find the blogpost saying what they do but now how.
I really wish nem provided more technical details for people who want to know how stuff works. I realize that this requires more time and effort but I think it’d be very valuable. When I look at the Ethereum blog I think it’s a perfect example of a blog that builds confidence in the devs. If nem has a similar blog even just explaining it’s features in detail I think it’d be a great asset not just a time sink as some might see it.

Yeah, I’d love to see that as well. There are currently community initiatives in place for more Catapult docs, so I believe we might be seeing technical explanations on these new updates soon (hopefully).