Farcaster Devs

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

>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

Hubs will need to verify the authenticity of the on chain events in the same way hubs verify the authenticity of Farcaster network messages. Reporting a false event would be a fault of the validator, which would result in other hubs rejecting the new block

BDFL of Quilibrium, Eng @ Farcaster, ex-Coinbase, always opinionated, never hydrated

/quilibrium

Makes total sense. What happens to all the other deltas / user actions included in that snap / block?

I know we trust validators significantly already, but if there's a bug, that means all other account updates get dropped if bundled with a bad event, right?

will go into the consensus model in more detail in the next post, but ideally we want bft-level tolerance, so that as long as > 2/3 of nodes are honest, the block will not get finalized.

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

Oh I understand that, but the question was more around what happens to innocent txs in a block that gets rejected?

Do they get dumped back into the mempool, or do they revert / fail to finalize and the end-user has to retry?

Implementation detail, but ideally mempools don't flush items until they're included in an accepted block

Makes sense, wonder if you'll need tx nonces then?

Wasn't sure if they were idempotent... was considering the case where add cast gets rejected, and then delete cast finalizes before it -- I suppose here, you can just no-op if you see a delete without an add. But from a user's standpoint, you've now failed to delete

I agree managing nonces client side is a hard no (pls)

Why would tx nonces help? Actions are (somewhat) idempotent, and a full week of historic transaction info (e.g. metadata, like the hash of the delta) being held in memory for fast conflict resolution avoids shifting the burden to the clients to manage nonces on behalf of every fid (or worse, every fid/signer combo)