Content
@
0 reply
0 recast
0 reaction
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 🧵👇
14 replies
10 recasts
38 reactions
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
Cassie Heart
@cassie
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
1 reply
0 recast
2 reactions
androidsixteen
@androidsixteen.eth
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?
1 reply
0 recast
1 reaction
Varun Srinivasan
@v
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.
1 reply
0 recast
2 reactions
androidsixteen
@androidsixteen.eth
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?
1 reply
0 recast
1 reaction
Cassie Heart
@cassie
Implementation detail, but ideally mempools don't flush items until they're included in an accepted block
1 reply
0 recast
1 reaction
