Content pfp
Content
@
0 reply
0 recast
0 reaction

androidsixteen pfp
androidsixteen
@androidsixteen.eth
Reading the Snapchain doc: https://warpcast.notion.site/Snapchain-Public-0e6b7e51faf74be1846803cb74493886 Going to cast all my stupid questions in this thread as they come up 🧵👇
15 replies
9 recasts
36 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
> We need a new architecture that guarantees: > 1. Decentralized global state — anyone download the entire network in a few hours. Given Snapchains enforce ordering, will Hubs have to replay state transitions like in blockchains to "sync" from checkpoints?
1 reply
0 recast
3 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
> Alice signs up. She creates an account using the Farcaster contracts on OP Mainnet which is picked up by the hubs and bundled into the first snap. What does "picked up by the hubs" mean? I'm assuming that Hubs monitor the FC contracts for events/logs and then take an action in response
1 reply
0 recast
2 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
What is the data structure for "Fid Roots"? Is it a list of all the roots (ie. n = number of users)?
1 reply
0 recast
3 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
> Snaps are produced by hubs every 15 seconds Does this mean any user action / delta will have a <15 second latency? So clients would optimistically display state changes before they're written to hubs?
4 replies
0 recast
7 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
> We can use this to simplify our network topology by introducing two types of hubs — write hubs and read hubs. Is it fair to compare these to "full nodes" and "block producers" I guess they'd be snap producers (oh snap)
1 reply
0 recast
8 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
>All snap data is verifiable through signatures included in the snap or by fetching onchain data from the Farcaster contracts on OP Mainnet. So a write hub can never publish false data. How do you prevent a hub from reporting false events / logs? Basically, how do you verify that the "bridge" from Ethereum is correct
1 reply
0 recast
2 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
@v @sanjay you guys should call them snaps 😉
1 reply
0 recast
3 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
> When a new snap is received each state change is applied onto the relevant trie which will add or remove items. Is there any concern around tree traversal for diff operations if users are reverting actions frequently? Ie. is this a spam vector? I like and unlike things wantonly
1 reply
0 recast
1 reaction

androidsixteen pfp
androidsixteen
@androidsixteen.eth
> The rule is that the snapchain can prune every snap after a week unless it contains the latest state transition for a user. Does this mean "dead" accounts (defined as accounts that stopped doing things on the network) impose a permanent cost that is at most 1 snap on hubs?
2 replies
0 recast
6 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
> This can be solved by fid based sharding — a simple scheme might introduce a write hub to handle all even numbered user accounts while another handles odd numbered ones. This is the coolest thing I've read in the doc so far Because there's *zero* contention, you can scale writes well via shards
1 reply
0 recast
10 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
>The right number is probably 10 - 20 globally distributed write hubs What was the reasoning behind this statement?
1 reply
0 recast
2 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
> Proof of Stake — Another approach is to follow Ethereum’s staking model. Anyone can run a Hub by staking ETH on a contract I think PoA would be better than this — this turns validator elections into an ETH bridging / event messaging problem, which is arguably worse
3 replies
0 recast
4 reactions

androidsixteen pfp
androidsixteen
@androidsixteen.eth
> delete — an operation that permanently evicts an add or remove delta from a hub I think y'all should use `evict` for this action @sanjay `delete` and `remove` are too similar and both are antonyms to `add`
0 reply
0 recast
7 reactions

Coop pfp
Coop
@coopahtroopa.eth
Good info here @ramie @sweetman.eth
1 reply
0 recast
4 reactions

koisose.lol pfp
koisose.lol
@koisose
i think only warpcast i saw supercast and pinata usually always in sync and neynar as well
0 reply
0 recast
0 reaction