From b2d694be259c3cea5f5fad14ad994480625f1543 Mon Sep 17 00:00:00 2001 From: Jane Wang Date: Thu, 15 Feb 2024 12:08:01 -0500 Subject: [PATCH 1/3] Update RPC docs for clarify on deprecation of postional array and costs (#721) * Update RPC docs for clarify on deprecation of postional array and costs * Update description on costs * Update in JSON-RPC info * Update transaction desc * Add build file * remove an extra file * modify the patch for the openrpc react package this will display our custom note following the parameters heading and before any of the named parameters are listed * remove the notes about by-name parameters in transaction params * add `deprecated` to the `cost` object in the tx simulation result * add the built `openrpc.json` file --------- Co-authored-by: Jane Wang Co-authored-by: Elliot Voris --- api/json-rpc.mdx | 8 ++++ openrpc/src/methods/simulateTransaction.json | 3 +- .../@metamask+open-rpc-docs-react+0.1.2.patch | 38 ++++++++++++++++++- static/openrpc.json | 3 +- 4 files changed, 49 insertions(+), 3 deletions(-) diff --git a/api/json-rpc.mdx b/api/json-rpc.mdx index d2004ce3..d78265a8 100644 --- a/api/json-rpc.mdx +++ b/api/json-rpc.mdx @@ -12,6 +12,14 @@ To interact with soroban-rpc from inside a JavaScript application, use the [Java When XDR is passed as a parameter or returned, it is always a string encoded using standard base64. +:::info + +Please note that parameter structure must contain named parameters as a by-name +object, and not as positional arguments as a by-position array. Positional +arguments as a by-position array will be deprecated in future RPC releases. + +::: + ## Open-RPC Specification Soroban-RPC provides an [OpenRPC] specification document that can be used to mock, build, and/or validate both server and client software implementations. This document is used to generate all of our [methods] documentation pages. You can view the full [specification document here]. Additionally, you can experiment with this specificaiton document in the [OpenRPC Playground]. diff --git a/openrpc/src/methods/simulateTransaction.json b/openrpc/src/methods/simulateTransaction.json index 0265feb8..cdf2bbc6 100644 --- a/openrpc/src/methods/simulateTransaction.json +++ b/openrpc/src/methods/simulateTransaction.json @@ -30,7 +30,8 @@ }, "cost": { "type": "object", - "description": "(optional) - Information about instructions used, etc. Not present in case of error.", + "description": "(optional) - The cost object is legacy, inaccurate, and will be deprecated in future RPC releases. Please decode transactionData XDR to retrieve the correct resources.", + "deprecated": true, "properties": { "cpuInsns": { "type": "string", diff --git a/patches/@metamask+open-rpc-docs-react+0.1.2.patch b/patches/@metamask+open-rpc-docs-react+0.1.2.patch index e87c94c4..61e8f0de 100644 --- a/patches/@metamask+open-rpc-docs-react+0.1.2.patch +++ b/patches/@metamask+open-rpc-docs-react+0.1.2.patch @@ -1,5 +1,5 @@ diff --git a/node_modules/@metamask/open-rpc-docs-react/dist/ExamplePairing/ExamplePairing.js b/node_modules/@metamask/open-rpc-docs-react/dist/ExamplePairing/ExamplePairing.js -index 354ce73..5e07a7f 100644 +index 354ce73..129371f 100644 --- a/node_modules/@metamask/open-rpc-docs-react/dist/ExamplePairing/ExamplePairing.js +++ b/node_modules/@metamask/open-rpc-docs-react/dist/ExamplePairing/ExamplePairing.js @@ -45,10 +45,37 @@ class ExamplePairing extends react_1.Component { @@ -93,3 +93,39 @@ index b8b0f3d..9a49549 100644 }; onExamplePairingChange?: (examplePairing: ExamplePairingObject | undefined) => void; reactJsonOptions?: object; +diff --git a/node_modules/@metamask/open-rpc-docs-react/dist/Params/Params.js b/node_modules/@metamask/open-rpc-docs-react/dist/Params/Params.js +index 4b059a6..b5dafce 100644 +--- a/node_modules/@metamask/open-rpc-docs-react/dist/Params/Params.js ++++ b/node_modules/@metamask/open-rpc-docs-react/dist/Params/Params.js +@@ -34,17 +34,20 @@ class Params extends react_1.Component { + if (!params || params.length === 0) { + return null; + } +- return (params.map((row, i) => react_1.default.createElement("section", null, +- react_1.default.createElement("h3", null, +- i + 1, +- ". ", +- row.name, +- (row.required === undefined || +- row.required === true) && +- react_1.default.createElement("span", { className: "content-descriptor-summary" }, +- react_1.default.createElement("i", null, +- react_1.default.createElement("small", null, " (required)")))), +- react_1.default.createElement(ContentDescriptor_1.default, { key: row.name, contentDescriptor: row, uiSchema: uiSchema })))); ++ return ( ++ [react_1.default.createElement("p", { key: "param-structure", className: "param-structure-requirement" }, "Please note that parameter structure within the request must contain named parameters as a by-name object, and not as positional arguments in a by-position array"), ++ ...params.map((row, i) => react_1.default.createElement("section", null, ++ react_1.default.createElement("h3", null, ++ i + 1, ++ ". ", ++ row.name, ++ (row.required === undefined || ++ row.required === true) && ++ react_1.default.createElement("span", { className: "content-descriptor-summary" }, ++ react_1.default.createElement("i", null, ++ react_1.default.createElement("small", null, " (required)")))), ++ react_1.default.createElement(ContentDescriptor_1.default, { key: row.name, contentDescriptor: row, uiSchema: uiSchema })))] ++ ); + } + } + exports.default = Params; diff --git a/static/openrpc.json b/static/openrpc.json index dd91ba16..64f86389 100644 --- a/static/openrpc.json +++ b/static/openrpc.json @@ -1049,7 +1049,8 @@ }, "cost": { "type": "object", - "description": "(optional) - Information about instructions used, etc. Not present in case of error.", + "description": "(optional) - The cost object is legacy, inaccurate, and will be deprecated in future RPC releases. Please decode transactionData XDR to retrieve the correct resources.", + "deprecated": true, "required": [ "cpuInsns", "memBytes" From 09509f784bc7ed3e536b4116429098a7b39bae46 Mon Sep 17 00:00:00 2001 From: Naman Kumar <330364+namankumar@users.noreply.github.com> Date: Thu, 15 Feb 2024 12:27:45 -0800 Subject: [PATCH 2/3] Update notes.mdx (#724) * Update notes.mdx * use audio tag for audio files * format --------- Co-authored-by: Tyler van der Hoeven --- docs/notes.mdx | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/docs/notes.mdx b/docs/notes.mdx index 53df8fa5..1cdc9fc3 100644 --- a/docs/notes.mdx +++ b/docs/notes.mdx @@ -21,6 +21,30 @@ description: Notes and recordings from the Soroban protocol & developers meeting 2. Stellar + Soroban documentation survey 1. [Take the survey](https://discord.com/channels/897514728459468821/1204462856037470248/1205196745877757962) +## 2024-02-01 + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1201979721211203614) + +1. The proposal is to advance stellar-core by adding a host function to verify the secp256r1 signature, which is the most common elliptic curve used outside of the blockchain space. It is useful in connecting off-chain authentication interfaces with on-chain functionality. +1. Note that the proposal is not for a new signer type but a host function. +1. Leigh investigated adding support for the WebAuthN use case, by allowing a custom account / smart contract to sign soroban auth entries using a secp256r1-signed payload. +1. secp256r1 is supported by phones, passkeys, and enables an app to replace passwords. This is a massive benefit to user-facing applications like wallets. +1. Pros and cons of the interface: blockchains generally implement the recovery interface over the verification interface but verification is easier for developers as it reduces burden on the client and the network. +1. The WebAuthN use case requires encoding and decoding of base64 payloads and decoding JSON blobs, which is not currently supported in Soroban. +1. While there are hacky ways of accomplishing the latter, it’s not a great developer experience and final implementation is susceptible to breakages on updates. +1. It is also costly to bundle decoding with verification in guest. +1. Soroban has always led with a batteries included mindset. Keeping in line with that approach, it makes sense to further investigate and determine whether a host function makes sense for these as well. +1. Leigh’s implementation may require further evaluation of the crates used for ecdsa and p256. +1. Brief discussion around proposed process for adding of a host function by a non-core dev. + ## 2024-01-26