Nano-node: Vote for Frontier

[Inkeliz]

The Bulk Pull makes it possible to get blocks from one account and the Bulk Pull By Account you can get the "frontier", but there's a way to check if you have the latest block and the right frontier.

I'm suggesting a new "FrontierReq" or change the current Bulk Pull By Account, which may work similar to the "ConfirmReq". The goal is to request one node if the hash is the latest in the chain.

The FrontierREQ might be:

• Public-Key (the PublicKey of the chain owner)
• Nonce (the unique random value)

The FrontierACK might be:

• Public-Key (the public key of the node)
• Signature (the signature of the FrontierReq + Hash)
• Hash (the hash of the frontier of the account previously asked)

The Goal:
Have a secure and reliable method to get the frontier hash, making it possible to verify the signature against the representative weight. It will be useful to implements in such a "Light-Wallets" (wallets running without the all ledger).

The Issue:
Today there's no way to check if you have the latest block. You can use the BulkPull or Bulk Pull by Account, but none provides a signature of this content.

The current "fix":
You can ask for votes, but a valid block doesn't mean that you have the last block. Today you must trust in the latest chain that the peers send to you (using the Bulk Pull or Bulk Pull By Account), it will work in most of the cases, but can fail if you have a fork in the chain, or all peers are desynced, or you are inside of a bubble connected against malicious peers. It will not lead you to lose money but will provide a terrible user experience, making it impossible to send coins.

[icarusglider]

You can already ask for the frontier of a specific account: https://github.com/alexbakker/gonano/blob/master/doc/protocol.md#frontier-req
Simply set count to 1, and ask a few peers to ensure consistency.

[Inkeliz]

You can already ask for the frontier of a specific account: https://github.com/alexbakker/gonano/blob/master/doc/protocol.md#frontier-req
Simply set count to 1, and ask a few peers to ensure consistency.

Amount of peers never should be the trust factor. If you connect to 1000 peers, but 990 are malicious, you get the wrong frontier. Simply because "it has more peer lying to you". Again, the wrong frontier will not lead you to lose your money, but creates an awful situation and will prevent to send/receive and may create a fork in the chain, which make things worse.

My suggestions of "FrontierREQ" (or "SignedFrontierREQ") will rely on the representative weight, not the how many peers are saying the same thing. The signature (and the nonce) will prevent some malicious node to send a wrong frontier. If the minimum quorum is not reached, the wallet can display a warning to the end-user or stop at all.

[icarusglider]

Then it would be a simple matter of asking one peer for the frontier and then broadcasting a confirm_req to get votes from all reps.

[Inkeliz]

Then it would be a simple matter of asking one peer for the frontier and then broadcasting a confirm_req to get votes from all reps.

Yes, but:

You can ask for votes, but a valid block doesn't mean that you have the last block.

A valid block doesn't mean that it's a frontier. Suppose that I have two blocks in my account (let's say one Open and another Receive), but remember that the wallet doesn't know anything. The Bulk Pull or FrontierReq could wrongly provide the hash of the first block (the Open). In that case, requesting the votes for that block (which isn't the frontier) will not confirm if that this block is the Frontier. The ConfirmReq response will confirm if the block is valid, in this case the block is valid, but doesn't have anything related to confirm if the block is the frontier.

The ConfirmReq doesn't fix this issue, as I previously said.

[clemahieu]

It sounds like you want a confirm_ack that also includes a bit saying this blocks is the frontier, is that accurate?

A couple things can happen, this bit can become invalid if another block comes in at the same time so at best it’s a best-effort indicator. It seems equivalent to the frontier_req + confirm_req in its best-effortness except it does it in one trip instead of 2.

[clemahieu]

I have considered adding two bits to the vote, one if it’s the frontier and another if it is receivable both in order to assist light clients.

Neither is 100% authorative because another block could race condition in and invalidate the bits or the one node could just lie, but the worst case is, as you said, a bad user experience where you need to query again.

[Inkeliz]

I have considered adding two bits to the vote, one if it’s the frontier and another if it is receivable both in order to assist light clients.

It'll be vulnerable to a replay attack. Every block will be "frontier" one time, some biased node can send the vote that has this bit true. So, everyone can store the vote which it's "Frontier=True".

To prevent this situation I mention the Nonce, to avoid anyone to store the vote and use in a point in the future. Because in that case, the vote must include the signature using the nonce.

[clemahieu]

Votes have a sequence number to prevent replays but even from an honest responder the block can become non-frontier during vote transit due to asynchronous events.

[Inkeliz]

The "sequence number" didn't work if you are connected only (or must) with the malicious/biased node. If everyone is honest, the FrontierReq and Bulk Pull will be enough, which is not the case.

If the wallet is connected with many malicious nodes, will be impossible t use the "sequence number", so this "Frontier=True" will be the last sequence number.

The "sequence number" only works if you have the new data to compare against the old one.

[clemahieu]

With your proposal if you’re only connected to malicious nodes, how will you get a reliable answer?

[Inkeliz]

You can't, but that is the trick. You can't, but because you can't you know that something is happening.

For comparison:

• Today the wallet will load and use the wrong frontier; The user may see a wrong balance and can't send or receive anything; But in the wallet point-of-view: it's indistinguishable, and the wallet has a valid frontier.

• My proposal: request the frontier using the weight of the representative (or a list of trusted representative....). If the representative didn't sign (or not reach the quorum) the wallet can detect that something terrible is happening; The user may receive a warning about what is happening; The wallet knows that the data (which may get from a malicious node) is highly possible to be invalid.

That is the difference. Today it's impossible to know if you have the right frontier. If this new method of "SignedFrontierReq" you will get the frontier or it will fail. If it fails, you know that something is happening and preventing from getting the right data, which is a good thing.

---

Wallet = "Light-Wallet" (without the ledger)

[clemahieu]

Alright, we’ll take a look at an interactive-style vote with a nonce instead of only a sequence number, probably the same time we look at adding durable votes.