Committee Node Liveness Proof via Lightweight Proof of Work

[shargon]

No description provided.

[roman-khimov]

1. A transaction with recent data is sufficient. I don't see how PoW improves anything compared to a simple automated transaction.
2. The mechanism must be optional. We have FS chains that are fully controlled by committee from main chain (that is validators list is set via RoleManagement), the mechanism doesn't make sense in that setting.

[roman-khimov]

Computing magic hashes is not something I'd expect in 2025. It's a waste of resources that Neo has always avoided. We don't need it.

[vncoelho]

1. A transaction with recent data is sufficient. I don't see how PoW improves anything compared to a simple automated transaction.

   2. The mechanism must be optional. We have FS chains that are fully controlled by committee from main chain (that is validators list is set via RoleManagement), the mechanism doesn't make sense in that setting.

From what I understood in the past we would proceed with recent data.
That recent data can be MPT, it can be some pieces of last consensus messages (for example some digits of 5 / 7 CN messages).

[roman-khimov]

That recent data can be MPT

C# nodes don't have it by default and neo-project/neo#4161 didn't happen. But can be considered if we're to require MPT. At least it requires state.

some pieces of last consensus messages

An interesting idea in that it can only be obtained if node really processes P2P traffic (can't be retrieved from chain), but it's weak at the same in that nodes can miss something because of communication problems.

StateRoot message (https://github.com/neo-project/neo-modules/blob/8c6b64b75cb2d133714d4a843f2dcb84dd16ddec/src/StateService/Network/StateRoot.cs#L25) comes to mind as well, but seems like it doesn't fit either, can be missed and witnesses can differ for different nodes.

[vncoelho]

That recent data can be MPT

C# nodes don't have it by default and neo-project/neo#4161 didn't happen. But can be considered if we're to require MPT. At least it requires state.

some pieces of last consensus messages

An interesting idea in that it can only be obtained if node really processes P2P traffic (can't be retrieved from chain), but it's weak at the same in that nodes can miss something because of communication problems.

StateRoot message (https://github.com/neo-project/neo-modules/blob/8c6b64b75cb2d133714d4a843f2dcb84dd16ddec/src/StateService/Network/StateRoot.cs#L25) comes to mind as well, but seems like it doesn't fit either, can be missed and witnesses can differ for different nodes.

I think that processing CN messages and select some bytes of the signature, let's say from the commit signature.
Based on the committee ID it pick that byte from the signature.
It is a trivial computation from nodes side and requires nodes to process P2P.
In my opnion it does not need to happen every round, let's say that it is a round robin, each block one committee should proof!
It can not fail more than X times.
All attempts are saved.

[Jim8y]

1. A transaction with recent data is sufficient. I don't see how PoW improves anything compared to a simple automated transaction.
2. The mechanism must be optional. We have FS chains that are fully controlled by committee from main chain (that is validators list is set via RoleManagement), the mechanism doesn't make sense in that setting.

maybe only mandatory for council node.

[shargon]

@roman-khimov Any ideas for a query that cannot be asked via RPC and proves the existence of the blockchain?

[shargon]

@vncoelho brain storm: how difficult could be add one primary step for committee, and every 8 blocks a committe member must sign a block?

[vncoelho]

@roman-khimov Any ideas for a query that cannot be asked via RPC and proves the existence of the blockchain?

This query I told you from consensus node messages can not currently.
However, one could provide a service that logs all messages and then this specialized service is used to provide information to each committee member, even if each of them has a unique rules.

[vncoelho]

@vncoelho brain storm: how difficult could be add one primary step for committee, and every 8 blocks a committe member must sign a block?

Easy but unnecessary.
I do not see any need of this primary step. What is the decision involved?
As I see it is just an information.
This can happen as a normal transaction or payload that is received at any time, there is no need for a specialized round/step.

[roman-khimov]

@roman-khimov Any ideas for a query that cannot be asked via RPC and proves the existence of the blockchain?

Well, what's a blockchain? A fancy state machine. This state changes with every block, so even if you're to try requiring something from block N it's not trivial to operate with that state at block N+1 (requires old state, likely MPT). Then all of the state data is available via RPC anyway, current always and historic in many cases as well. So anything state-related doesn't seem to be adding any value.

To be fair, if we're considering a deliberate attack on consensus with bad actor controlling at least F+1 nodes no scheme can help us. The attacker can pretend it's all fine and even run consensus normally with any additional dances around it and then just kill nodes when he has enough control and he wants to do it. Like NGD currently controls 3/7 CNs, they're running fine, but ultimately they have the power to kill the network, easy as that.

So likely we want to protect from more accidental breakage that can occur if a committee member doesn't have any node at all and he's promoted to CN. A simple heartbeat transaction is sufficient for this, we have MVUBI requirements and to prevent presigning a lot of transactions we can require some recent block hash to be present in this transaction. To me that's about it, at least this proves that the key isn't lost and some code has online access to it. Normally it'd be a node with dBFT enabled, just the easiest way to satisfy the requirement.