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

POC Signature aggregation API #368

Merged
merged 55 commits into from
Aug 8, 2024
Merged

POC Signature aggregation API #368

merged 55 commits into from
Aug 8, 2024

Conversation

iansuvak
Copy link
Contributor

@iansuvak iansuvak commented Jul 15, 2024

Why this should be merged

This will close #361 and represents a minimal mergeable implementation of the Warp Signature aggregation API. It maintains all functionality of the existing relayer implementation and adds the new binary running the signature aggregation portion.

How this works

  • Moves the logic requesting signatures that was previously in the application_relayer.go to it's own file in signature-aggregator/aggregator.go which is imported by the relayer.
  • It re-uses the existing peers package including AppRequestNetwork but slightly modifies it to be able to accept the simplified config from signature-aggregator
  • It doesn't maintain any persistent state or follow the chains and instead expects the user to supply the raw bytes to be signed. It uses the legacy AppRequest interface to request signatures but will switch to using the ACP-118 defined once it's implemented in coreth. subnet-evm implementation is already done.
  • The required configuration is minimal by design and doesn't support manually defining source/destination chains/subnets.

Code organization

  • Currently there is anew signature-aggregator directory containing all files specific to the new API including it's config and network implementation.
  • There is a new lib folder containing some common interfaces and structs used by both configs and networks. Some of the network code in particular should be deduplicated.
  • Minor changes were made to the awm-relayer network implementation to be able to share interfaces for signature aggregation in the future.

How this was tested

Existing e2e tests pass and a new e2e test was added. Note that currently it will only work for messages originating on the P-Chain until avalanche go 1.11.11 (and matching coreth/subnet-evm) is released as a required networking fix to bypass trackesSubnets check has only recently been merged to master branch.

How is this documented

README.md with overview and example manual testing flow was added.

signature-aggregator/config/keys.go Fixed Show fixed Hide fixed
signature-aggregator/config/keys.go Fixed Show fixed Hide fixed
signature-aggregator/main/main.go Fixed Show fixed Hide fixed
@iansuvak iansuvak self-assigned this Jul 16, 2024
@michaelkaplan13
Copy link
Collaborator

The interface aims to be destination chain agnostic and doesn't ask for destination blockchain. Although we might have to add it as a required field when the source is pChain?

I don't think so. For messages from P-chain -> Subnet, the SigningSubnetID will be set as the subnet itself, but we shouldn't need any "destination chain" either way 👍

lib/aggregator.go Outdated Show resolved Hide resolved
signature-aggregator/config/config.go Outdated Show resolved Hide resolved
signature-aggregator/config/source_blockchain.go Outdated Show resolved Hide resolved
scripts/build.sh Outdated Show resolved Hide resolved
@feuGeneA feuGeneA removed this from the Signature Aggregator API - MVP milestone Jul 26, 2024
before this, it was being rendered as:

INFO [07-29|19:29:09.151] Starting the signature aggregator with config at :%s /home/gene/tmp/signature-aggregator-config.json61842304=<nil> LOG_ERROR="Normalized odd number of arguments by adding nil"
"Starting the signature-aggregator executable" message already exists
elsewhere. This differentiates this log entry from that one.
config/config.go Outdated
return c.PChainAPI
}

// Config implempents the peers.Config interface

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense and is a nit, but can we still add it? We have it in other places of the repo, and believe it's a standard go practice

&cfg,
)
network.InitializeConnectionsAndCheckStake(&cfg)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we remove the pass by ref here, want to avoid it being unintentionally altered

signature-aggregator/README.md Outdated Show resolved Hide resolved
signature-aggregator/README.md Show resolved Hide resolved
signature-aggregator/aggregator/aggregator.go Outdated Show resolved Hide resolved
signature-aggregator/aggregator/aggregator.go Outdated Show resolved Hide resolved
signature-aggregator/aggregator/aggregator.go Show resolved Hide resolved
)

const (
RawMessageAPIPath = "/aggregate-signatures/by-raw-message"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good with signatures/aggregate

signature-aggregator/api/api.go Outdated Show resolved Hide resolved
signature-aggregator/api/api.go Outdated Show resolved Hide resolved
iansuvak and others added 4 commits August 6, 2024 11:15
Co-authored-by: cam-schultz <78878559+cam-schultz@users.noreply.github.com>
Co-authored-by: F. Eugene Aumson <feuGeneA@users.noreply.github.com>
Co-authored-by: minghinmatthewlam <matthew.lam@avalabs.org>
Signed-off-by: Ian Suvak <ian.suvak@avalabs.org>
signature-aggregator/config/keys.go Dismissed Show dismissed Hide dismissed
signature-aggregator/config/keys.go Dismissed Show dismissed Hide dismissed
Comment on lines +36 to +39
type AggregateSignatureResponse struct {
// hex encoding of the signature
SignedMessage string `json:"signed-message"`
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should consider returning the P-Chain height corresponding to the signature's canonical validator bit vector. Without it, there's an implicit "expiration" on responses from the API. With it, the caller would be better able to implement checks against the current state of the P-Chain before sending a tx to deliver the Warp message.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to add this to follow up. Since we are already changing interfaces there for ACP-118. But I do think that the implicit P-chain height is current height and the general workflow is request it and send it immediately. Failure in that case is extremely unlikely but a simple retry of the full flow should be an easy fix.

Copy link
Collaborator

@cam-schultz cam-schultz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of final nits, otherwise LGTM

}
```

## Sample workflow
If you want to manually test a locally running service pointed to the Fuji testnet you can do so with the following steps.

Note that this might fail for older messages if there has been enough validator churn, and less then threhold weight of stake of validators have seen the message when it originated. In this case try picking a more recent message.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Note that this might fail for older messages if there has been enough validator churn, and less then threhold weight of stake of validators have seen the message when it originated. In this case try picking a more recent message.
Note that this might fail for older messages if there has been enough validator churn, and less then the threshold weight of stake of validators have seen the message when it originated. In this case try picking a more recent message.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Expanding this to 1) explain that the Warp protocol does not support resigning, but 2) protocols on top of Warp such as Teleporter do (and link to the relevant docs)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just left a comment on your PR but I will link to the doc section once they are merged in main. I don't really want to over-elaborate here beyond linking since this is just a sample testing flow to make sure that the service works as expected.

Co-authored-by: cam-schultz <78878559+cam-schultz@users.noreply.github.com>
Signed-off-by: Ian Suvak <ian.suvak@avalabs.org>
signature-aggregator/README.md Outdated Show resolved Hide resolved
signature-aggregator/aggregator/aggregator.go Show resolved Hide resolved
signature-aggregator/aggregator/aggregator.go Show resolved Hide resolved
signature-aggregator/aggregator/aggregator.go Outdated Show resolved Hide resolved
Comment on lines 410 to 413
return signedMsg, true, nil
}
// Not enough signatures, continue processing messages
return nil, true, nil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think I prefer explicitly returning nil

signature-aggregator/aggregator/aggregator.go Show resolved Hide resolved
signature-aggregator/api/api.go Outdated Show resolved Hide resolved
signature-aggregator/main/main.go Outdated Show resolved Hide resolved
Co-authored-by: Geoff Stuart <geoff.vball@gmail.com>
Signed-off-by: Ian Suvak <ian.suvak@avalabs.org>
Copy link

@minghinmatthewlam minghinmatthewlam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly LGTM my end, just leftover comments Geoff pointed out

Copy link
Contributor

@geoff-vball geoff-vball left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@iansuvak iansuvak merged commit b5fbbe8 into main Aug 8, 2024
7 checks passed
@iansuvak iansuvak deleted the signature-aggregation-api branch August 8, 2024 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[POC] - Warp Signature Aggregation API
6 participants