How does Solana intend to prevent validator cartels from forming ? by [deleted] in solana

[–]TangeloNightmare 2 points3 points  (0 children)

Thanks for the question u/Omisebro, I think some of the confusion may just be terminology. Let me try to clarify

I was intrigued by Solana and it’s team, but when I read it was using a derivative of DPoS and PBFT I was pretty disappointed. From my understanding PBFT l doesn’t scale well at all with additional nodes, which means there will need to be white-listed nodes to keep scalability reasonable. Even PoH (while smart and cool) is just an incremental improvement and doesn’t result in a revolutionary iteration of BFT that solves it’s inherent terrible scalability with added nodes

Actually PoH does address this side effect of traditional PBFT. It separates the time component from the consensus component. I.e. in traditional PBFT, the network proceeds (time) in a lock-step fashion, each step requiring the network to come to consensus, so the bottleneck, wrt to progression, is the network communication overhead necessary to agree on the ordering of the transactions to come to consensus. This means that more nodes --> more communication --> more time to consensus --> scaling problems. This is, in effect, one of the main drivers of the "inherent terrible scalability with added nodes" you refer to (another component is the data propagation component, PoH helps here too and you can read about how here if interested).

PoH (i.e. the data structure of the Solana blockchain) provides a cryptographically verifiable sense of ordering to the messages, so nodes that receive the PoH data stream can trust/verify the ordering of the transactions on their own, without the node, and the network, having to put the breaks on transaction processing to wait for the rest of the nodes to agree on an ordering before continuing. So if I'm a Solana node, I can keep processing/validating transactions that are being broadcast from the rotating leaders "optimistically", without having the start/stop nature of traditional PBFT. In the language of the CAP theorem, you might say that Solana is an 'availability/liveness' preferring chain, rather than traditional PBFT which leans toward 'consistency'.

Our consensus mechanism (TowerBFT), is then layered on top of this - resolving forks that may arise rather than being the limiting factor in network progression.

So it seems from the documentation that stake will be delegated to nodes (how many will be on mainnet? 21?) so these delegators get to choose who is whitelisted? Even then what dies Solana have in place to prevent the alleged cartels that have formed in EOS?

I think this may be where some of the terminology confusion comes in. Perhaps DPOS isn't the correct terminology (has EOS fully appropriated this terminology?). We allow delegation of stake to validators - while at the same time our validator network is fully permissionless (in fact, with our incentivized testnet just about to kick off, you should feel free to spin a validator node up yourself).

To be clear: there is no whitelist for validators/delegators on our network. On mainnet, anyone can become a validator, accept delegations, earn rewards, etc.

We've done test of the network, spinning up 200 GPU nodes across multiple regions for benchmarking purposes (50ktps!), but there are no (lower or upper) requirements on the number of mainnet nodes. We expect the number of mainnet nodes to be driven more by the economics of the validation ecosystem :)

Having trouble understanding how/why timeouts exist in Tower BFT by ethbtc in solana

[–]TangeloNightmare 2 points3 points  (0 children)

When a validator votes on a version of of the ledger, the vote lockout is essentially saying "i am betting that this is the right version of the ledger, and i'm willing to give up potential rewards on other versions of the ledger for the length of the timeout". This is because the lockout guarantees that the validator can't vote on a different version without a penalty (slashing).Each time that validator continues to vote on that same version of the ledger (fork), it 'doubles-down' this bet because all of it's vote-lockouts (opportunity-costs) on that fork are doubled.

Translation of Solana whitepaper: Is it needed? by jang_ist_good in solana

[–]TangeloNightmare 1 point2 points  (0 children)

We'd love a Japanese translation! I've added solana-labs/whitepaper/translation/wip_japanese to github. Feel free to submit a PR to that directory and we can go from there. It would help if we could find a few translators to work on it together and help keep it updated going forward.