Farcaster

Farcaster Devs

The snap chain design is cool, but its weak point is validator election.

My concern is that once we move to system where 10 or 20 people or entities have the power to censor the network, it will eventually happen. Once we get there it will only be a matter of time, for someone to suggest that validators must censor topic A or fid B, and use social, legal or regulatory pressure to do so. 

I even guess that from day 1, there will be some geographies that implicitly or explicitly won't be able to host validators. China? Russia? Does the EU live up to the standards of the 10 voters?

Do we really think that the 6 validators (even if they are not located in the US) will not comply with a decision of a US court or regulator that asks them to censor any FID associated somehow with an OFAC-sanctioned wallet? And do we want them to have to fight this fight?

I have huge respect for the people that worked on the design, this is not an attack, but we have to have this discussion. I want to be convinced that I'm wrong.

@vrypan raises an important point about the tradeoffs of snapchains design. If we only have 10 nodes that can validate messages isn’t that bad for decentralization? 

Let’s start with the problem that Snapchain is solving. Our deltagraph network lets any hub add a new message at any time. As the network grows, failures between nodes increase and delays become inevitable. 

You have to be able to “check” your sync state with a large percentage of the network in a short amount of time and this breaks down quickly. When it does, users will complain about messages moving very slowly between apps, which will make them less likely to use Farcaster, and less likely for apps to be built.

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

Bitcoin and Ethereum solve this by letting only one node (roughly) earn the right to produce the next block. If everyone knows the change is coming from one place and things are ordered, sync is much simpler. 

Base and OP Mainnet (on which FC is built) go even further and have a single node produce all the blocks today. This is even more efficient, but one criticism is that you can be censored. 

This doens't happen as much in practice because there are technical (if not simple) ways to work around this by getting your transaction included into the L1. The existence of this safety valve makes censorship impractical.

Farcaster’s Snapchain is going to have stronger decentralization than L2’s.

There will be 10 sequencers chosen by the community that would all have to collude to block someone. And even if they did, someone could post their signed message on X and prove to everyone that Farcaster was censoring them. Censorship will be impractical. 

We also have short term plans to make the decentralization much stronger.

We can increase decentralization by: 

1. Increasing the number of validators (10 -> 100 is  feasible with some R&D) 
2. Switching to proof of stake — allow people to stake Ethereum to become block producers, so there is no voting 
3. Use verifiable compute mechanisms — validators can be asked to include data without knowing the user that sent it 

We are not locked into a model that isn’t extensible, we have many levers we can pull to keep improving decentralization.

We need to reach a level of sufficient decentralization that balances protocol decentralization with developer experience. We think that snapchain with 10 nodes meets the bar today, and there is a reasonable path to extending it to greater levels of decentralization over the next 3-5 years.

Should we be pushing more aggressively to reach a higher level of decentralized today, instead of next year?   

Practically speaking, if Dan and I turned evil and wanted to block someone, we’d just do it at the Warpcast. That would kill 90% of someone’s traffic and be far more efficient than trying some sort of validator attack. 

The weakest point in the armor is Warpcast.  What will solve this is multiple clients — we need to make it easier and easier to build more apps on the network. That’s the most important priority for sufficient decentralization.

The issue with the block proposer that @vrypan suggested is that it makes sync much harder, which makes it harder to build clients. If Supercast keeps having sync issues, theyll have a hard time acquiring users and the network will remain practically centralized, no matter what we do at the protocol.

Protocol censorship is impractical in the short term: 

* we do not have a monopoly on reach like Twitter
* you have to convince 10 validators, and not a single sequencer like in the L2 case 
* client censorship is much easier and equally effective 

The most important form of decentralization we need to reach is multi client. 

And if the protocol design makes it harder to build clients that seems like a bad tradeoff to make

>someone could post their signed message on X and prove to everyone that Farcaster was censoring them. Censorship will be impractical.

january 2021, the whole world new trump was being censored but that didn't make censorship impractical. 

comparing rollups pushing tx to L1 to pushing a cast to X is bad analogy. it works for L2s because L1 is fully censorship resistant but X is not. 

p.s. i understand that we might not want to prioritize full censorship resistance rn. and that's ok.