simple partial-verifier#62
Conversation
- calculates pending verifications on startup - fetches the state on both source and destination chains - verifies the parameters and 'signs' if they're correct
- created a new module for signing-related configuration - parse signing/group configuration from local files - start an in-memory event bus - fetch pending verifications - print a signature over them
3c66875 to
58c4af4
Compare
1425328 to
79344b6
Compare
79344b6 to
268357d
Compare
- extracted signing/shared config into its own crate - refactored signals into an easy struct
that hangs on the signing part right now heh. Might need some configuration still - libp2p configuration layer - libp2p networking using the group file - some tests around the configuration just for sanity
AnomalRoil
left a comment
There was a problem hiding this comment.
Half-way through, but here's a first batch of comments before lunch
- added a README for the onlyswaps verifier - updated the submodule name from onlysubs to onlyswaps - renamed group to committee and some other notions around it - combined keyshare and committee configuration
azixus
left a comment
There was a problem hiding this comment.
nearly done, still need to go through signing.rs & pending.rs
| t = 2 # the honest threshold required for reconstruction. This is *different* to the malicious threshold output by the [ADKG CLI](../crates/adkg-cli) | ||
| n = 3 # the total count of members in the committee, including yourself. | ||
|
|
||
| # `committee.nodes` should contain as many entries as `n` above, and should contain one for your own node. |
There was a problem hiding this comment.
That's a weird requirement. I'd expect our own node identity to be defined elsewhere
Do we check the public key corresponds to the secret key above?
There was a problem hiding this comment.
it's this way because otherwise we have to rely on:
- operators removing their own entry in the group file
- allowing indexes being 'missing' at the end
we don't presently verify that the public key corresponds to the secret key; ...truth be told I'm not even sure this is even corresponding to the keyshare and not their own BN254 key
| pub fn reconcile_transfer_params( | ||
| src_params: SwapRequestParameters, | ||
| dest_receipt: TransferReceipt, | ||
| ) -> anyhow::Result<SwapRequestParameters> { |
There was a problem hiding this comment.
Why are we not checking anything wrt to the request_id here?
Same about the nonce field?
How comes the latter is not verified to be unique / not have been seen before in here? Also, what is its purpose vs the request_id in general?
I guess the underlying question is: what prevents a replay here?
E.g. the same request is made again by the user, for the same amounts same source and destination, and all, but with a new nonce and a new request ID, obviously, and the last solver replays their first solve, without having solved the new request
There was a problem hiding this comment.
requestID embeds a bunch of params about the tx, most notably the chainID; nonces are governed by the smart contract, so we can't reuse a (chainID, nonce) combo.
In theory, we might reuse a nonce if we deploy multiple Router contracts with the same committee - we could consider embedding the Router contract address to stop that if you think it's necessary. cc @najienka
There was a problem hiding this comment.
Damn, beat me to it by 2 days :p
4d27c1d to
035a55f
Compare
| pub fn reconcile_transfer_params( | ||
| src_params: SwapRequestParameters, | ||
| dest_receipt: TransferReceipt, | ||
| ) -> anyhow::Result<SwapRequestParameters> { |
There was a problem hiding this comment.
Damn, beat me to it by 2 days :p
caveats
there are a few ugly unwraps in the loopsprintln!instead of usingtracing