feat: introduce basic multisig message support #1025
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
byte-bandit
force-pushed
the
clohr/op-keys
branch
from
126af48 to
af8ce1b
Compare
byte-bandit
commented
Nov 9, 2023
byte-bandit
force-pushed
the
clohr/op-keys
branch
from
6632e50 to
cf028ea
Compare
byte-bandit
changed the title
verabehr
approved these changes
Nov 9, 2023
taariq
approved these changes
Nov 9, 2023
Not for this one, the Pigeon one will contain one though. |
3 tasks
byte-bandit
added a commit
to palomachain/pigeon
that referenced
this pull request
Nov 10, 2023
# Related Github tickets - VolumeFi/paloma#857 - VolumeFi/paloma#934 - palomachain/paloma#1025 # Background In order to support multiple signing keys for Pigeons, we recently released a change for Paloma that introduced message metadata fields for all Paloma messages, allowing Pigeons to define signers other than the creator address. This change includes: - Removing lens as a dependency, replacing it with a slimmed down in-house solution called `ion` - Support to define multiple signature keys in the pigeon config, see below for additional details - Automatic key rotation when sending messages to Paloma - Automatic metadata injection into messages - Introducing `validator-key` as a configuration field for the paloma chain inside Pigeon. This used to be the `signing-key` field, which remains to be supported for now The new signing keys are completely optional. In case there's no change to the configuration, Pigeon will read the old existing `signature-key` field and use it for both the message creator and signer when injecting metadata. See below on how to enable support for multiple signing keys. Going forward, we'll be referring to the old `signing-key` as `validator-key`. #### Support for multiple signing keys By default, Pigeon will use your validator key to sign any transactions sent to Paloma. In high throughput environments, this may lead to `account sequence mismatch` errors. It's possible to define more than one signing key to be used in rotation to combat this issue. In order to do so, you will need to create a number of new keys and register them with Pigeon like this: ```bash # First, create a number of new keys. You may create an arbitrary amount of keys. palomad keys add pigeon-operator-alpha palomad keys add pigeon-operator-bravo palomad keys add pigeon-operator-charlie # Second, your new addresses will need to receive an active feegrant from your validator address. # This step is very important. It's not enough to simply fund those addresses manually. # The active feegrant is considered a "permission" to send transactions from your validator address". palomad tx feegrant grant $VALIDATOR_ADDRESS pigeon-operator-alpha --fees 500ugrain -y palomad tx feegrant grant $VALIDATOR_ADDRESS pigeon-operator-bravo --fees 500ugrain -y palomad tx feegrant grant $VALIDATOR_ADDRESS pigeon-operator-charlie --fees 500ugrain -y ``` After creating your signing keys, all you need to do is register them with Pigeon by adding the following to your pigeon config. Make sure to restart the service after making these changes. ```yaml paloma: signing-keys: - pigeon-operator-alpha - pigeon-operator-bravo - pigeon-operator-charlie ``` # Testing completed - [x] test coverage exists or has been added/updated - [x] tested in a private testnet # Breaking changes - [x] I have checked my code for breaking changes --- * feat: support multiple signing keys with rotation * fix: use master address when sending messages * fix: dead lock on mutex acquisition * feat: add fee grant * chore: add logging * feat: inject message metadata * fix: retrieve signer address for metadata * fix: remove superfluous logging * feat: remove locking from paloma calls * fix: use paloma wrapper constructor * chore: remove all lens dependencies * fix: CI pipeline * chore: move signature keys configuration to paloma only * chore: update go.mod paloma reference * doc: update README
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related Github tickets
Background
This change introduces a couple of new concepts into the Paloma ecosystem:
metadata, which itself includes two different fields:signersandcreator.Using these new concepts, Paloma now considers the metadata field contents when verifying transaction signatures. It does so by confirming that the transaction contains signatures from:
a) all signers of every message within the transaction
b) ensuring that the message creator is among the set of signers, or at least one of the signers of a message has active feegrant from the message creator
This allows us to start using more than one key when signing transactions, as long as those keys are feegranted from our validator account. It also sets the stage for multisig transaction verifications on our end.
Testing completed
Breaking changes