FIP: Address race conditions between username proof and username add

[aditiharini]

Title: Address race conditions between username proof and username add
Type: Implementation FIP
Authors: @aditi, @sanjay

Abstract

Introducing a way to solve cases where a username update is rejected because the associated username proof has not been processed by Snapchain.

Problem

We often encounter cases where a UserDataAdd message with UserDataType.USERNAME is submitted to Snapchain shortly after the associated UserNameProof message. In some of these cases, the UserDataAdd message is rejected by Snapchain because the UserNameProof has not been merged yet because it’s in the mempool waiting to get processed or it’s in a proposed block that hasn’t been confirmed.

There are 2 problems to solve

1. The Snapchain RPC server will reject the UserDataAdd message as a part of its validation because it will not be able to find the UserNameProof until it’s merged.
2. The consensus logic in Snapchain will reject the UserDataAdd message if it’s in the same transaction as the associated UserNameProof message.

Specification

Implement the SubmitBulkMessages endpoint

This endpoint was supported on hubs and this implementation is fully backwards compatible with the hubs implementation.

message SubmitBulkMessagesRequest {
  repeated Message messages = 1;
}

message BulkMessageResponse {
  oneof response {
    Message message = 1;
    MessageError message_error = 2;
  }
}

message SubmitBulkMessagesResponse {
  repeated BulkMessageResponse messages = 1;
}

rpc SubmitBulkMessages(SubmitBulkMessagesRequest) returns (SubmitBulkMessagesResponse);

Clients who are registering an ENS name or a Basename should submit the UserNameProof then the UserDataAdd in that order in a single call to the SubmitBulkMessages endpoint. If a new verification is needed for the UserNameProof that should also be submitted in the same call to SubmitBulkMessages, before the UserNameProof. This way, the SubmitBulkMessages endpoint can validate each message with all the dependencies in context.

const claim = makeUserNameProofClaim({
  name: 'farcaster.eth', 
  owner: '0x...',
  timestamp: Math.floor(Date.now() / 1000),
});
const signature = (
  await accountKey.signUserNameProofClaim(claim)
)._unsafeUnwrap();
const dataOptions = {
  fid: 123, 
  network: FarcasterNetwork.MAINNET,
};
const signer = new NobleEd25519Signer(accountEd25519Key);
const usernameProofMessage = makeUsernameProof(
  {
    name: claim.name,
    owner: claim.owner,
    timestamp: claim.timestamp,
    fid: dataOptions.fid,
    signature: signature,
    type: UserNameType.USERNAME_TYPE_ENS_L1,
  },
  dataOptions,
  signer
);
const usernameMessage = makeUserData(
  {
    type: UserDataType.USERNAME,
    value: claim.name,
  },
  dataOptions,
  signer
);
await rpcClient.submitBulkMessages(SubmitBulkMessagesRequest { messages : [usernameProofMessage, usernameMessage]})

If only some of the messages are valid, the valid messages will pass through and the invalid ones will be rejected. The SubmitBulkMessagesResponse contains an indication of which messages are accepted and which are rejected.

Allow for a UserDataAdd message to be processed in the same transaction as a UserNameProof it depends on

This requires a change in the Snapchain consensus logic to introspect the currently active and uncommitted RocksDB transaction for relevant data in addition to the already committed data. There’s no client facing impact.

Rationale

Does this solve for the case where the user is registering an fname?

No, the race condition will still exist for the fname case because fnames are not submitted to Snapchain by clients and are ingested directly from the fname server. There is some delay between a username being received by the fname server which the client cannot control. The long term solution to this problem is to have fnames be managed by Snapchain directly but this is not in scope right now. In the short term, we will have Snapchain poll the fname server more frequently so there’s less delay between when a fname is registered via the fname server and when Snapchain knows about it. Snapchain is already capable of processing a username in the same transaction as the associated fname.

Release

The consensus-level Snapchain changes will be under a protocol release. We will release Snapchain version x.y.z on or before yyyy-mm-dd with changes taking effect one week following the release. The new SubmitBulkMessages endpoint can be released independently in a patch release.

[vrypan]

Is there a reason why we don't just instruct clients to check that UserNameProof has been merged before submitting UserDataAdd? It seems to me like something that can be easily resolved client-side, without moving the complexity to Snapchain.

That's additional lines of code we will carry forever, and my conflict with something else we may want to implement in the future, or one more flow that can't be broken in the future.

[aditiharini]

Yeah it's possible to check this but
(1) It delays or at least complicates onboarding flows for clients to wait for the username proof to get merged before submitting the username.
(2) It's not super convenient to wait for the username proof. The client needs to have some mechanism for waiting without blocking and also needs to decide how long to wait for the UserNameProof before declaring failure. If the mempool is full you may have to wait more than 1s.

The SubmitBulkMessages flow was actually something we added to hubs to reduce the burden of reconciliation flows where clients submit many messages in quick succession on hubs. This likely won't be the only use-case for SubmitBulkMessages which is a motivating factor for this approach.

[vrypan]

I understand this. But, let's be clear. In this context "the clients" is Farcaster and TBA. When you say "it complicates the flows for clients", or " it's not super convenient", you are talking about the guys sitting next to you at the office (figuratively).

You could say that in many cases, we have implemented features that all they do is make developer lives easier, but the underlying concept is if we didn't, some of these developers or teams would not build for Farcaster. But in this case, from the protocol POV, what's the benefit?

I'm not against implementing SubmitBulkMessages (which btw, was introduced to hubs silently, when it was introduced), because it makes hubs more efficient. If I were a hub, I'd say, "yes, please, don't make 100 requests, if you can put everything in one".

My objection is to "Allow for a UserDataAdd message to be processed in the same transaction as a UserNameProof it depends on". In which case, if I were a hub, I would be "hey, why do you complicate my life"?