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

Lido offchain plugins p1 #435

Merged
merged 16 commits into from
Sep 7, 2023
Merged

Lido offchain plugins p1 #435

merged 16 commits into from
Sep 7, 2023

Conversation

luketchang
Copy link
Contributor

@luketchang luketchang commented Sep 5, 2023

Motivation

Start offchain work needed to support Lido. OpRequestBuilder.build() needed to be async due to plugins like Uniswap needing to make network calls for fetching routes.

Solution

  • Split op request builder plugins out of core package (e.g., don't want to import uniswap sdk into core)
  • Refactor builder to collect array of plugin fn promises that resolve to unwraps, actions, refunds, and metadatas to enqueue
  • Add wsteth adapter plugin which supports sending ETH to wsteth in return for wsteth
  • NOTE: we still don't have plugins for swapping out of wsteth back to weth (coming in next PR with Uniswap plugin)

Proof

https://www.loom.com/share/6e5d5094613247788783baedf0e16b63?sid=b4ade8b1-a86c-4613-99f0-f38bad62b579

PR Checklist

  • added tests
  • updated documentation
  • added changeset if necessary
  • tested in dev/testnet
  • tested site with snap (we haven't automated this yet)
  • re-built & tested circuits if any of them changed
  • updated contracts storage layout (if contracts were updated)

@changeset-bot
Copy link

changeset-bot bot commented Sep 5, 2023

🦋 Changeset detected

Latest commit: 7e96332

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 15 packages
Name Type
@nocturne-xyz/core Major
@nocturne-xyz/op-request-plugins Patch
@nocturne-xyz/frontend-sdk Patch
@nocturne-xyz/e2e-tests Patch
@nocturne-xyz/deploy Patch
@nocturne-xyz/idb-kv-store Patch
@nocturne-xyz/local-prover Patch
@nocturne-xyz/persistent-log Patch
@nocturne-xyz/bundler Patch
@nocturne-xyz/deposit-screener Patch
@nocturne-xyz/insertion-writer Patch
@nocturne-xyz/subtree-updater Patch
@nocturne-xyz/test-actor Patch
@nocturne-xyz/snap Patch
@nocturne-xyz/offchain-utils Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@luketchang luketchang marked this pull request as draft September 5, 2023 03:27
Copy link
Contributor Author

luketchang commented Sep 5, 2023

Current dependencies on/for this PR:

This comment was auto-generated by Graphite.

@luketchang luketchang changed the title WIP: lido offchain plugins WIP: lido offchain plugins p1 Sep 5, 2023
@luketchang luketchang changed the title WIP: lido offchain plugins p1 Lido offchain plugins p1 Sep 5, 2023
@luketchang luketchang marked this pull request as ready for review September 5, 2023 14:32
@luketchang luketchang mentioned this pull request Sep 5, 2023
7 tasks

// add a plugin promise to await, resolves to unwraps, refunds, and actions to enqueue
// returns `this` so it's chainable
pluginFn(pluginPromise: Promise<PluginFnResult>): this;
Copy link
Contributor

Choose a reason for hiding this comment

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

we can probably have a better name than pluginFn - instead, how about enqueueAsyncPlugin or something like that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

well the its not the plugin itself that's being called, a function on the plugin (plugins will have multiple methods). Think this is probably fine. Fn or call but same thing

@@ -5,10 +5,13 @@ import { Action, Address, Asset, OperationMetadata } from "../primitives";
const ONE_DAY_SECONDS = 24 * 60 * 60;

// A joinsplit request is an unwrapRequest plus an optional payment
export interface JoinSplitRequest {
export interface JoinSplitRequest extends UnwrapRequest {
Copy link
Contributor

Choose a reason for hiding this comment

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

Kinda nit, but this type is effectively saying a JoinSplitRequest is a special case of UnwrapRequest, when we really want the opposite semantics - UnwrapRequest is a special case of JoinSplitRequest.

We can get the latter semantics via the following:

export interface JoinSplitRequest {
  asset: Asset;
  unwrapValue: unwrapValue;
  payment?: ConfidentialPayment;
}

export type UnwrapRequest = Omit<JoinSplitRequest, "payment">;

Here, a JoinSplitRequest is not assignable to a variable of type UnwrapRequest, but an UnwrapRequest is assignable to a variable of type JoinSplitRequest


### Unreleased

- Package name migrated from `sdk` to `core`
Copy link
Contributor

Choose a reason for hiding this comment

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

clear changelog entries from core/sdk

...inner,
use: use,
convertWethToWsteth(amount: bigint) {
const prom = new Promise<PluginFnResult>((resolve) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

technically don't need to enqueue a promise here, as there's no async.

Copy link
Contributor Author

@luketchang luketchang Sep 6, 2023

Choose a reason for hiding this comment

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

Well its for type consistency since we want all plugins to add to same array and have same interface to live by (enqueue actions, unwraps, refunds for op request builder to handle at .build()). Other option is to just push directly to array but would rather keep devX consistent across plugins

Copy link
Contributor

Choose a reason for hiding this comment

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

this is not what the ERC20 plugin is doing - in this case we should force it to enqueue a promise as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

oh oops I see.

Copy link
Contributor

@Sladuca Sladuca Sep 6, 2023

Choose a reason for hiding this comment

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

should we also make the "base" methods all enqueue promises as well then? Someone could do something like:

await builder
  .use(Erc20Plugin)
  .transfer(...) // async
  .unwrap(...) // sync
  .build()

in .build(), the unwrap() will be applied before, not after the transfer

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I can do this for consistency

use: use,
convertWethToWsteth(amount: bigint) {
const prom = new Promise<PluginFnResult>((resolve) => {
const chainId = this._op.chainId;
Copy link
Contributor

Choose a reason for hiding this comment

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

we might need to be careful how this gets bound in the closure. It could very well be that if you call use after calling convertWethToWsteth here, the this inside the closure could be pointing to the pre-extension builder

Copy link
Contributor Author

Choose a reason for hiding this comment

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

not sure I'm understanding, what might happen here?

Copy link
Contributor

@Sladuca Sladuca Sep 6, 2023

Choose a reason for hiding this comment

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

suppose user does something like:

builder
  .use(Erc20Plugin)
  .transfer(...)
  .use(SomeOtherPlugin)
  .someOtherPluginMethod(...);

when .transfer(...) is called, it'll create a closure over a context where this points to the builder object returned by .use(Erc20Plugin) and pass it into the promise constructor. Then the second call to .use(SomeOtherPlugin) is gonna return a new object with all of the methods / properties copied over, but the context closed over by the closure created during transfer(...) will still have this pointing to the object returned by .use(Erc20Plugin).

This isn't really an issue to fix as much as it is something I wanted to flag that I noticed just now - this might be a problem with the current synchronous implementation (honestly not sure how "object methods" get their this bound when they're copied to another object), but it's definitely a problem here depending on whether shallow or deep copies are being made (and it's not immediately clear to me which is the case, it may actually depend on the properties / plugins involved)

@luketchang luketchang force-pushed the luke/lido-offchain branch 2 times, most recently from 090e0e9 to 7448898 Compare September 7, 2023 03:21
@luketchang luketchang enabled auto-merge (squash) September 7, 2023 15:49
@luketchang luketchang merged commit 6abd69b into main Sep 7, 2023
3 checks passed
@luketchang luketchang deleted the luke/lido-offchain branch September 7, 2023 16:03
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.

2 participants