Content
@
0 reply
20 recasts
20 reactions
Varun Srinivasan
@v
@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.
5 replies
29 recasts
184 reactions
Varun Srinivasan
@v
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.
2 replies
0 recast
62 reactions
Varun Srinivasan
@v
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.
3 replies
0 recast
11 reactions
kia
@kia
>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.
1 reply
0 recast
0 reaction
Varun Srinivasan
@v
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
1 reply
0 recast
0 reaction
kia
@kia
i understand that it's impractical. that was my p.s. i wouldn't prioritize it either if i was the bd. that really doesn't mean we should compare to stuff like l1/l2 where properties are different. it's a bit of a stretch frankly. we should just own up to the state of things.
1 reply
0 recast
0 reaction
Varun Srinivasan
@v
we should always compare our tradeoffs to other real-world decentralized systems. no analogy is perfect but its useful to think through what tradeoffs other systems are making and how they are playing out in the arena.
0 reply
0 recast
0 reaction