Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(vc): stronger p2p message abstraction #7682

Closed
Tracked by #7681
Maddiaa0 opened this issue Jul 30, 2024 · 1 comment
Closed
Tracked by #7681

chore(vc): stronger p2p message abstraction #7682

Maddiaa0 opened this issue Jul 30, 2024 · 1 comment

Comments

@Maddiaa0
Copy link
Member

Overview

This PR has a lower priority, the p2p layer involves some pretty repetitive abstractions.

export class AztecTxMessageCreator {
  private readonly topic: string;
  constructor(version: SemVer) {
    this.topic = `/aztec/tx/${version.toString()}`;
  }

  createTxMessage(tx: Tx) {
    const messageData = tx.toBuffer();

    return { topic: this.topic, data: messageData };
  }

  getTopic() {
    return this.topic;
  }
}

P2P messages are created in the above way, where a tx is attached to a serialized message of the above type.

There then must exist a propogate and handle method for all differing transaction types

  public propagateTx(tx: Tx): void {
    void this.jobQueue.put(() => Promise.resolve(this.sendTxToPeers(tx)));
  }

As I understand it we will need different handle methods for each type of P2P message, however the logic to propagate a message is the same for each type of message.

As we will not have a large variety of messages, it is not a priority to rewrite the current implementation to support this, however if things expand, it will simply the code surface

@Maddiaa0
Copy link
Member Author

fixed in #7733

@github-project-automation github-project-automation bot moved this from Todo to Done in A3 Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

1 participant