Sanjay

@sanjay

209 Following

4089 Followers

Sanjay pfp

Should be fixed now

0 reply

0 recast

2 reactions

Sanjay pfp

Looks like we're consistently running ~4mins behind since last night. Looking

1 reply

0 recast

2 reactions

Sanjay pfp

Not any more. All current messages require ED25519.

0 reply

0 recast

2 reactions

Sanjay pfp

What exactly do you mean by "client side"? The best way to validate a message is to call the validateMessage endpoint on the Hub. databytes is optional, you need to protobuf encode the message to verify the signature, see https://github.com/farcasterxyz/hub-monorepo/blob/aa9cde7543886e7d109ab81877a23646d1cbbfe8/packages/core/src/validations.ts#L312-L322. But note that this is only a small part of what the hub does to consider a message "valid". A few other important steps are to ensure that the signer is still active and that it's associated with the same fid as the message. You might also need to do other validations depending on what you're looking for. Take a look at validateMessage function in engine/index.ts for a more complete view.

1 reply

0 recast

1 reaction

Varun Srinivasan pfp

Varun Srinivasan

One point of feedback we got on the Snapchain design doc is that we didn't fully explain why sync in the current model is a problem. @sanjay wrote up a good thread on our internal slack, which i'll try to summarize below. https://warpcast.notion.site/Snapchain-v2-Public-10e6a6c0c101807aadfacbcddda8ce4f?pvs=74

3 replies

37 recasts

245 reactions

Sanjay pfp

If you query the contactInfo object for the peer, it should have the dns name if the hub is configured correctly (hoyt should be announcing it's DNS name for example). We have to handle this case for syncing see code here on how to translate from the ContactInfo into a working RPC client https://github.com/farcasterxyz/hub-monorepo/blob/1ca66d8cf21c5c98e084175a2bba4b803a85da07/apps/hubble/src/hubble.ts#L1730

1 reply

0 recast

1 reaction

Sanjay pfp

YUou can try connecting via the insecure client first, and then if it fails, try with the SSL client. We do a variation of that here: https://github.com/farcasterxyz/hub-monorepo/blob/1ca66d8cf21c5c98e084175a2bba4b803a85da07/apps/hubble/src/hubble.ts#L1707

1 reply

0 recast

0 reaction

Sanjay pfp

1-5s should be plenty. It could take longer if the hub is under a lot of load. But the actual call should be pretty fast.

1 reply

0 recast

1 reaction

Sanjay pfp

Not yet, it's too early to say right now.

0 reply

0 recast

0 reaction

Sanjay pfp

For inclusion into a block, you only need 1 honest validator. Then if 2/3rds of validators collude to reject the block, you have signed messages as proof of rejecting/skipping a valid block. What is the benefit for colluding at the validator level to censor messages? Snapchain does not hold value, It's not like you're preventing access to the user's funds. The user can easily post the signed message to any other social network/github/eth/btc and get their voice heard. A typical farcaster message is ~150 bytes, small enough that for the small number of users at such extreme risk of censorship, the protocol could support nodes updating user state by listening to calldata on an L2, or blob storage on eth L1.

1 reply

0 recast

3 reactions

Sanjay pfp

The 10 is just to start with. I do think all active fids should have a say eventually. But not sure exactly what that looks like. I looked at an earlier version, but not recently. Will take another look.

0 reply

0 recast

2 reactions

Sanjay pfp

OFAC only applies to financial transactions. At least in the US, I don't think validators can be legally compelled to censor speech. That said, we do take this attack vector seriously, and have some ideas on how we can address it. 1. Simplest version is a vote to replace the validator that's rejecting/skipping valid blocks. 2. Second simplest is increase geographic distribution. We can scale to ~50-100 nodes per shard if required with only slight impact on block times. 3. Allow the user to pick the shard. Validator sets will eventually be unique per shard. This is not possible for every user, but users that need it can register their shard preference in a smart contract which is respected by the protocol. 4. A variation of eth's inclusion lists to force validators to include messages 5. Finally, you could post merkle roots/messages to a smart contract and force inclusion to read nodes. Does not scale, but works for users at extreme risk of censorship. I don't think we'll need to go beyond 1 and 2 though.

2 replies

0 recast

1 reaction

Sanjay pfp

0 reply

0 recast

1 reaction

Sanjay pfp

Hmm, what kind of issues were you running into with shuttle? Do you happen to have any logs? Happy to help debug, please DM. cc @nikolaiii too.

1 reply

0 recast

2 reactions

Sanjay pfp

If it fits your needs feel free to use it, just note that it might be subject to change since it’s pretty new.

0 reply

0 recast

0 reaction

Sanjay pfp

It’s meant to provide a performance and reliability improvement when doing long running sync and reconciliation jobs.

1 reply

0 recast

0 reaction

Sanjay pfp

Generally we keep the changes backwards compatible. You shouldn't need to bump every version.

1 reply

0 recast

0 reaction

Sanjay pfp

Yes, practically with most consensus algos you need 2/3rds to be honest. However, because we don't have to worry about double spends or changing history as much, we have more flexibility. There are escape hatches you can build in. One version is you could pay publish your fid merkle root to a public smart contract that all hubs listen to, and then "publish" your entire account state to a read hubs which will get propagated across the network (as long as the messages are valid and compute to the same merkle root). Ultimately, I'm a fan of Varun's "sufficient decentralization". If we can get to ~5-10 geographically distributed hubs run by independent entities, and fids have a say in who those entities are, it's good enough for the medium term. Since Farcaster is fundamentally a social protocol, the ability for social consensus to keep hubs honest should not be underestimated. Especially compared to other chains.

1 reply

0 recast

1 reaction

Sanjay pfp

Yes, we could do something like that. But it doesn't have to happen at the block level. It could happen once a month/quarter/year etc. With fids voting (as you imply it has issues, need sybil resistance) for the set of fids running a write hub. Another mechanism we discussed briefly is that we could allow users to pay a small fee and pin which block producer you want to messages to be included in. e.g. if you are worried about collusion among write hub operators and being censored. Ideally we just need one honest hub, but something to think about.

1 reply

0 recast

1 reaction

Sanjay pfp

I don't think that would be possible without introducing crytpoeconomic incentives for security. I think we can move to a more open system for hubs eventually, with just staking eth.

1 reply

0 recast

0 reaction