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.
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 https://github.com/ethereum/wiki/wiki/Governance-compendium, particularly against on-chain governance in this context.