PIP-27: Pruned Node

[ja7ad]

PIP-27: Pruned Node

[kehiy]

@ja7ad @b00f @pactus-project/research-reviewer I think it's better to call it light node or light client since every protocol did it. I mean everyone knows this concept as the light client so it can cause misunderstanding.

[b00f]

In my opinion, a light client should refer to a type of client that doesn't verify everything—maybe only new blocks without validating transactions.

[kehiy]

I agree with that.

[kehiy]

@ja7ad @b00f @pactus-project/research-reviewer

PIPs/PIPs/pip-27.md

Line 87 in 35f8769

### Importing Data

In this case, the pruned node is downloading only some part of the chain! not the whole chain from Genesis, so can we still trust the centralized server by verifying?

We are only verifying and seeing some parts of the chain, is there any way for manipulation by a centralized server?

And one more important issue, we are syncing some blocks at all, what about indexed data extracted from transactions? balances, stakes, and in future contracts states?

When we have a whole chain, we can retrieve states by reading whole blocks and indexing the changes that a transaction makes, such as bonding a new validator, sending a native coin, or a contract deploy.

But when we don't have the whole chain we need these data and we need to verify them as well.

[b00f]

If the data you receive from the centralized server is manipulated, you can't sync the data and the chain.
The specification should be modified. Instead of copying the data, we have to iterate over blocks to ensure all the block have valid signature and in the last block the state hash is the same as sate hash inside the block.

[kehiy]

How it can calculate the state hash when the light node doesn't have the old blocks and states?

Such as balances or stake amounts? One way is to sync with the whole chain for 1 time and then remove old blocks.

But keeping the state without blocks can still be a lot if we are thinking about storage.

Also, I think the only thing reduced in this proposal is the storage and the process cost and network cost are the same.

With a simple compare and looking at blow chart for example, we can find out the storage is not a serious issue, at most this pruned node can make it half. (for now makes 500Mb -> 250Mb)

[b00f]

How it can calculate the state hash when the light node doesn't have the old blocks and states?

Once you have the latest state of blockchain, including all accounts and validatos, you can calculate the state hash. Here

But keeping the state without blocks can still be a lot if we are thinking about storage.

Agree, but still we have less data to store.

[kehiy]

Once you have the latest state of blockchain, including all accounts and validatos, you can calculate the state hash. Here

So, we need to sync with the state too, correct? In this case, this is a good model.

About storage, I think I was wrong. we have much less data. we don't have all TXs changing 1 balance integer. we keep only an integer for a balance and it means less data.

But one more question here: A pruned node can't really prove the state it has based on history. like asking where this 1000 PAC comes into this smart contract or validator? so it can't provide a detailed history of it.

Of course it's not required for pruned nodes and we don't expect it, but can it cause security issues?

[ja7ad]

PIP-27 for implementation accepted, Issue address is: pactus-project/pactus#1390

[b00f]

@kehiy

Let's remove the check on downloaded data that seems redundant to me.
Consider an adversary who can change all blocks and transactions up to the last one.
After 10 days, the corrupted block will be pruned, giving no advantage to the adversary.

[b00f]

Please review: #164

[kehiy]

@b00f That's OK, but we must keep one thing on PIP.

We need to keep verify or your explanation here about why we don't need to verify if we don't say anything about it it's not logical.

[kehiy]

I Checked the changes on PIP now, looks good to me.