androidsixteen on Warpcast

Content pfp

0 reply

0 recast

0 reaction

androidsixteen pfp

@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 🧵👇

14 replies

10 recasts

38 reactions

androidsixteen pfp

@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.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.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

androidsixteen pfp

@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.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.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.eth

@v @sanjay you guys should call them snaps 😉

1 reply

0 recast

3 reactions

androidsixteen pfp

@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.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.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.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.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.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

Coop pfp

@coopahtroopa.eth

Good info here @ramie @sweetman.eth

0 reply

0 recast

4 reactions