White paper notes

[jcray (James Ray)]

Link to the paper from pokt.network

I haven’t finished re-reading it yet, more notes will probably follow.

Remove bootstrapping sequence: centralized DNS seeds (see also discussion in the last protocol meeting notes: link to other post with my notes on that)

Identifying nodes by IP reduces privacy.

Pocket Edge Node selected by geolocation proximity: may be insecure, reduces randomness, especially with sufficiently lower participation. Explore other ways to ensure relaying is optimized, as well as through non-monetary, technical measures such as gossipsub and extensions to gossipsub such as episub.

Incentivizing a Robust P2P Network/Relay Layer

Delegating the responsibility for a pseudo random generation (e.g. of Edge nodes to generate Validator Nodes) seems like a bad idea. Ethereum 2.0 will use a beacon chain, where validators are pseudorandomly shuffled as attesters and proposers (one proposer per slot, some attesters per slot). What if the edge node foregoes generating the validator set? The economic cost to the system may be very high, and putting down a deposit this high to be slashed would not be viable, and increase centralization.

Why would a service node broadcast the data back to the application client that originally send the request for that same data to be relayed? You should distinguish between data that the application client has and cases where it is requested data to be relayed which it does not have (e.g. applications such as oracles). Ah, judging by the diagram on the following page, it is not a request for data that the client does not have to be relayed to the client.

Majority consensus should be more than 2/3 of validators weighted by deposit, or the same fraction of a committee/subset of validators.

Should you separate concerns of validators and relayers, or consider any inequalities, asymmetries of incentives, or non-equilibria? There would be a lower barrier to entry to be a validator if they only validate/attest/vote, not also relay which requires bandwidth. Generallly, think about incentive alignment and mechanism design. Ah, but if they submit the signed relay batch, that seems OK.

Earlier you have devID then on p. 9 end of col. 1 you have developerID. Pick devID for brevity and consistency.

Public addresses should be hashed, not used directly.

Developer Policies: need to be careful with governance mechanisms, ensuring e.g. Sybil resistance which is difficult to achieve electronically (AFAIK it hasn’t been achieved) and enforceability of policies. Fluctuating policies would create uncertainty and could cause more harm than good.

Designated minter? Be careful about allocating that responsibility. Opens all kinds of attacks including censorship and bribing.

“The network security relies on the integrity and solidarity of the Federated Nodes. Think about how to design for when the majority is not honest, there is collusion, etc.”

I really dislike DPOS, irrespective of how many additions there are for security against delegate, finding another solution is, IMO, essential to the sustainability of the protocol. I clarified with Michael that full PoS is planned to be used, not DPOS. I assume that means that you aren’t going to use federated nodes.

Get other blockchain security analysts to review.

IMO, focus minimally on marketing. Publish with major release updates, recruit as needed, and let the product market itself, unless that doesn’t work even with a good product. Once a good product is developed, start applying it.

Edit: Further notes

Nit p. 13. You have [xxxx] under the Block Validation heading. Maybe use a hidden comment if this is a reminder to insert something like a citation.

Nit col. 2. Transfering → Transferring

I’m also leery of karma scoring mentioned e.g. on p. 13, it’s a form of voting on reputation, while AFAIK no method of voting in digital systems has been proven to be sybil resistant. However, I should also note that voting with attestations is critical in Eth2, while it doesn’t really matter as voting is weighted by stake held as a percentage of total stake, so if the same weighting mechanism is used here I guess it should be OK.

Section 3.5, p. 14, col. 2, known attack vectors. It would be good if you could formally prove the safety of the protocol in terms of liveness and consistency and security under different models such as honest majority, honest minority, network synchrony, cryptoeconomic / bribing attacker. If you use a PoS protocol that already has a formalized proof such as Casper CBC TFG or FFG, there’s a safety argument here with a link to the original paper, although neither of these have been fully implemented yet.

p. 17. Governance. See also Governance compendium · ethereum/wiki Wiki · GitHub, particularly against on-chain governance in this context.

[Andrew (Andrew Nguyen)]

Good notes.

Centralized DNS seeds

As discussed in the meeting, this was just a layer for nodes to bootstrap. By no means is the Pocket Network going to have a centralized bootstrapping sequence. This is simply a centralized option to join. Removal of this tier of bootstrapping may be inevitable due to security concerns, but our priority when designing the bootstrapping sequence was flexibility and redundancy.

Identifying nodes by IP reduces privacy

Agreed, IP was thinking more MVP.

Pocket Edge Node selected by geolocation proximity: may be insecure, reduces randomness, especially with sufficiently lower participation. Explore other ways to ensure relaying is optimized, as well as through non-monetary, technical measures such as gossipsub and extensions to gossipsub such as episub.

Good note. Interestingly enough, we recently have discussed removing this feature of PN due to the changing nature of the dispatch sequence.

Delegating the responsibility for a pseudo random generation (e.g. of Edge nodes to generate Validator Nodes) seems like a bad idea. Ethereum 2.0 will use a beacon chain, where validators are pseudorandomly shuffled as attesters and proposers (one proposer per slot, some attesters per slot). What if the edge node foregoes generating the validator set? The economic cost to the system may be very high, and putting down a deposit this high to be slashed would not be viable, and increase centralization.

This reminds me of what @luyzdeleon proposed with the chain of responsibility. This is a good idea ^

Why would a service node broadcast the data back to the application client that originally send the request for that same data to be relayed? You should distinguish between data that the application client has and cases where it is requested data to be relayed which it does not have (e.g. applications such as oracles). Ah, judging by the diagram on the following page, it is not a request for data that the client does not have to be relayed to the client.

1. Client sends request
2. Service Node Responds to Client
3. Service Node Relays request to validators
4. Validator Nodes Validate

Note: The client sends data from step 2 to prevent the SN from sending correct data to the validator set and incorrect data to the client.

I hope this helps answer your question. It may be helpful to provide page numbers so I can see where you are at.

Designated minter? Be careful about allocating that responsibility. Opens all kinds of attacks including censorship and bribing… I really dislike DPOS, irrespective of how many additions there are for security against delegate, finding another solution is, IMO, essential to the sustainability of the protocol. I clarified with Michael that full PoS is planned to be used, not DPOS. I assume that means that you aren’t going to use federated nodes.

Designated Minter is an outdated concept. We are now using full PoS to designate minter. The federation does not play a role in the blockchain consensus. The federation is for relay validation.

[jcray (James Ray)]

The federation does not play a role in the blockchain consensus. The federation is for relay validation.

Right, looks like the white paper needs to be rewritten then. I am still skeptical of using federated nodes with high stake in any context, including at a network level with relay validation, as there is a risk of cartelization and collusion (the high stake excludes most people who can’t afford it), rent seeking with higher relay fees, censorship risk, and a resulting poorer experience for users. Even the paper identifies a one-kill-at-a-time collusion attack, without proposing a solution, while transactions could also be censored. Speculating, maybe liveness faults could occur if a cartel of federated nodes blocked all relays as invalid for a time, although I suppose that new nodes could fairly quickly form to replace the cartel.

A cartel or majority could also commit a takeover bribing attack, while federated nodes do not participate in consensus, they could still potentially control a longer running new canonical chain to be created by relaying blocks that are created by validators randomly shuffled as block proposers that enter into a bribing contract, which would potentially create liveness faults or block skips if validators that aren’t in the bribing contract propose blocks and such blocks don’t get relayed due to being voted by the majority cartel as invalid. Relying on a user-activated soft fork to overcome such attacks is not a good thing to do, IMO.

See also:

An alternative to federated nodes for relay validation

Use a committee to attest to the validity of relays. From Eth2 shasper: Committee - a (pseudo-) randomly sampled subset of the active validator set. When a committee is referred to collectively, as in “this committee attests to X”, this is assumed to mean “some subset of that committee that contains enough validators that the protocol recognizes it as representing the committee”.

[o_rourke (Michael O'Rourke)]

I am still skeptical of using federated nodes with high stake in any context, including at a network level with relay validation, as there is a risk of cartelization and collusion (the high stake excludes most people who can’t afford it), rent seeking with higher relay fees, censorship risk, and a resulting poorer experience for users

This is something @Tracie and I briefly spoke about yesterday. Though it hasn’t been decided, I believe the amount to stake to be a federated should be less than a blockchain consensus node.

Section 3.3.1 in the paper explains the process to become a Federated Node.

Use a committee to attest to the validity of relays. From Eth2 shasper: Committee - a (pseudo-) randomly sampled subset of the active validator set.

This committee concept is exactly what we’re doing to determine the Validator set in a given session. Now that I’m looking through the paper it’s not clearly defined, but the Validators in a given session will be chosen randomly and based off various factors such as time staked.

For example, you have a Validator set of 3, and the protocol chooses a committee of 3 from a set of 300 where 100 are considered “new stake”, 100 are “medium stake” and 100 are “long stake” in terms of time. Dash does something similar in their protocol to minimize the odds of collusion as well.

[BenVan]

… I am still skeptical of using federated nodes with high stake in any context, including at a network level with relay validation, as there is a risk of cartelization and collusion (the high stake excludes most people who can’t afford it), rent seeking with higher relay fees, censorship risk, and a resulting poorer experience for users…

I appreciate the skepticism, but would like to point out that this is a lot like the discussion of 51% attacks on a POW blockchain. The federated nodes are the most vetted, most invested, largest risk takers and greatest service providers on the network. Note that all federated nodes by definition are also service nodes, and dispatch nodes. Rent seeking, censorship and any other behavior which decreases the utility, reliability, or reputation of the network is not in their best interest.

[jcray (James Ray)]

This is something @Tracie and I briefly spoke about yesterday. Though it hasn’t been decided, I believe the amount to stake to be a federated should be less than a blockchain consensus node.

OK, that does alleviates concerns somewhat. 32 ETH is planned to be required in the eth2 spec), with 8 or 16 s slot periods, 2^22 as the max. validator count, and 128 as the min. committee size, with a rationale for that latter parameter here on slide 10: https://vitalik.ca/files/Ithaca201807_Sharding.pdf, “a 2^(-40) chance of a 1/3 attacker getting a 2/3 committee”. Given this I would say the numbers in your example are too low, even with federated nodes not participating in blockchain consensus.

For example, you have a Validator set of 3, and the protocol chooses a committee of 3 from a set of 300 where 100 are considered “new stake”, 100 are “medium stake” and 100 are “long stake” in terms of time. Dash does something similar in their protocol to minimize the odds of collusion as well.

I appreciate the skepticism, but would like to point out that this is a lot like the discussion of 51% attacks on a POW blockchain. The federated nodes are the most vetted, most invested, largest risk takers and greatest service providers on the network. Note that all federated nodes by definition are also service nodes, and dispatch nodes. Rent seeking, censorship and any other behavior which decreases the utility, reliability, or reputation of the network is not in their best interest.

We shouldn’t give them the chance to get away with attacks, potentially unnoticed. They may try to get away with bad behaviour and even view that such behaviour and costs associated with it are an acceptable way of doing business, while profits are worth the costs. Censorship has been done in EOS. With only 3 validators / fed. nodes in a committee, 51% attacks are not the only kind of attacks that they can do. If there is insufficient validation and offchain validation of validation (e.g. Truebit-style, STARKs, or re-execution), they may well get away with it.