search

input-output-hk / smart-contract-backend

Work in progress: Run off-chain smart contract executables server-side in isolation, accessible via a network interface
Apache License 2.0
8 stars 1 forks source link

Define new EUTxO client wallet API to include required endpoints #18

Open rhyslbw opened 5 years ago

rhyslbw commented 5 years ago

The following items are functions of the wallet that are currently not exposed for API consumers:

  1. Submitting signed transactions, one or many Required for #20
  2. Getting the UTxO set for a given address or addresses Required for #19

Emulator's existing Servant API https://github.com/input-output-hk/plutus/blob/master/wallet-api/src/Wallet/Emulator/Http.hs

rhyslbw commented 5 years ago

https://github.com/input-output-hk/plutus/blob/master/wallet-api/src/Wallet/Emulator/Http.hs#L121-L126

submitTxn ::
     (MonadReader ServerState m, MonadIO m, MonadError ServantErr m)
  => Wallet
  -> Tx
  -> m [Tx]
submitTxn wallet tx = runWalletAction wallet $ WAPI.submitTxn tx >> pure [tx]

In the wallet API, the current transactions endpoint: https://cardanodocs.com/technical/wallet/api/v1/?v=1.4.1#tag/Transactions%2Fpaths%2F~1api~1v1~1transactions%2Fget

/api/v1/transactions/

Maybe for now we can suggest basing on transactions/signed until the Externally Owned Wallet schema is developed, and leave submitTxn as is

rhyslbw commented 5 years ago

Proposal to query for a UTxO set based on provided addresses (one or many): https://cardanodocs.com/technical/wallet/api/v1/?v=1.4.1#tag/Addresses addresses/utxos/{addresses}

Sam-Jeston commented 5 years ago

I agree that we should propose the transactions/signed endpoint. Maybe if we ask purely for that endpoint in isolation, it can be developed with higher priority. It will require further digging from our end to figure out what kind of arguments it would take. Will dive into the Yoroi codebase to see what I can find.

I agree that the existing UTxO set endpoint will likely do the trick

rhyslbw commented 5 years ago

addresses/utxos/{addresses} doesn't exist, this is my proposal for where it could be positioned though

rhyslbw commented 5 years ago

Hey @KtorZ. Linking you to this for a review of the proposed endpoints discussed above. As discussed we can first implement in the EUTxO emulator maintained by the Plutus team, but the schema would be good to define now for easy migration to the cardano-wallet API later.

rhyslbw commented 5 years ago

Hey @shmish111 please check this out. The linked issues will add context, and relate to the discussion we had on Thursday. Could the existing Wallet HTTP API be used to front the EUTxO core? If so, the extension could be hosted as a separate HTTP service, and reduce maintenance.

shmish111 commented 5 years ago

@rhyslbw could you explain more about which parts you want to reuse? The infrastructure, the code, which code? Sorry I don't quite get it yet.

rhyslbw commented 5 years ago

@shmish111 No problem. The isolated off-chain script would be a consumer of the node's Wallet API over HTTP, and may expect access to this interface https://cardanodocs.com/technical/wallet/api/v1/?v=1.4.1 . Is this the case, or does the contract have access to a different range of wallet functionality to what https://github.com/input-output-hk/cardano-wallet defines?

shmish111 commented 5 years ago

Ah, that I'm not sure of, maybe @j-mueller can answer?

KtorZ commented 5 years ago

Note that the API specified for 1.4.1 is going to be deprecated soon enough and will be replaced by a brand-new version which includes support for delegation. I'd advise not to get attached too much to anything from the current codebase and especially the "V1 API" from 1.4.x & 1.5.x

Having said that, I am quite foreign / not very aware of the details related to this project (the smart contract API). So, I'll only give my two cents for what I am able to answer at this moment:

The two points mentioned earlier:

  1. Submitting signed transactions, one or many
  2. Getting the UTxO set for a given address or addresses

are on our roadmap for the upcoming months. We haven't however specified the API endpoints for those. Quickly skimming through https://github.com/input-output-hk/plutus/blob/master/wallet-api/src/Wallet/Emulator/Http.hs#L121-L126 and the associated types, I can already tell that we'll have rather different ways of modelling transactions and their parameters. I'd love to hear about the requirements here and what exactly is needed for you guys (maybe, a slightly more detailed version of the two bullet points above).

edit: If this can be of any help / interest. Here's the new API we are working on, and that will soon be extended with the points above: https://rebilly.github.io/ReDoc/?url=https://raw.githubusercontent.com/input-output-hk/cardano-wallet/master/specifications/api/swagger.yaml

rhyslbw commented 5 years ago

Thanks @KtorZ We will discuss this in our weekly meeting and get back to you. I'm hoping the Plutus team can collaborate with you on cardano-wallet to add support for the EUTxO model, even if it means maintaining a fork until the project is in a position to consider the requirements of smart contracts.

https://github.com/input-output-hk/plutus/blob/master/docs/extended-utxo/README.md#wallet-api-for-scripts

j-mueller commented 5 years ago

@KtorZ Thank you for the links to the new API. I will have a look at the documentation and then I'll probably bother you with some questions.