Varun Srinivasan
@v
We're starting to think about a new sync model for Farcaster. The current system works but is unlikely to scale up another 10x. Here's our articulation of the problem we want to go after.
15 replies
81 recasts
440 reactions
jj 🛟
@jj
https://storage.googleapis.com/gweb-research2023-media/pubtools/1974.pdf https://github.com/cockroachdb/cockroach/blob/master/docs/design.md There are some incredible things that Spanner and Cockroachdb does for globally distributed databases - the kv rocksdb design that the hubs do are similar to what cockroachdb does actually maybe can borrow more ideas from them. Incredible people over there.
1 reply
0 recast
5 reactions
Cassie Heart
@cassie
spanner and cockroachdb rely on trusted components – spanner has massive time synchronization techniques to get intra-server time as precisely aligned as possible, which does nothing in the adversarial distributed consensus category. cockroachdb uses a significantly narrowed version of rocksdb (pebble) that they layer on top of. I've had a decent amount of experience now (unfortunately) dealing with pebble's shortcomings, to the point I had to vendor a fork of it just to get it to behave the way i needed for another decentralized protocol.
1 reply
0 recast
3 reactions
jj 🛟
@jj
Cockroachdb folks use a slightly different technique that’s a bit more forward looking called Hybrid Logical Clock to get around spanner’s atomic clocks. Agreed it’s a different problem, but when it comes to global replication I’d say there’s some learnings https://cse.buffalo.edu/tech-reports/2014-04.pdf
1 reply
0 recast
1 reaction
Cassie Heart
@cassie
100% – the distributed adversarial conditions that exist in trustless timestamping are a bit more challenging, but there are some strong approaches: obviously blockchain (w/r/t proof of work) was the first idea that solved it, but since then there's been approaches like incorporating verifiable delay functions to serve as a lamport clock timestamping basis. It's still not perfect, but definitely doable. Hubs have _less_ of a timestamping issue and more of a distributed consensus problem with CRDTs, in that the span of CRDTs being consumed in a given sync period are too large to reconcile across all parties in a timely basis. The "all parties" is the sticking point – because the moment any hub(s) become "preferred" it turns into a credible neutrality problem.
1 reply
0 recast
1 reaction
