Homework 7: Add NL Interactivity to your Uniswap UI

Goal

●   Add natural language interactivity to the Uniswap UI you built in homework 6.

● Natural language instructions

○    Using natural language, a user should be able to:

■    deposit, redeem, or swap

●    Examples:

○    “swap 10 USDC for eth”

■    LLM should convert this to call of:

●    swapExactTokensForTokens(

○    uint amountIn,

○    uint amountOutMin,

○    address[] calldata path,

○    address to,

○    uint deadline)

○    “deposit 5 Tether and 3 wbtc”

●    Sequence of steps upon user entering NL instruction (NLI):

○    Convert NLI to a structure representation SR.

■   Text-to-sql is an example of this operation:

●    convert from natural language to structured data

■   function calling is another example

●    convert from natural language to API

○    Convert the SR into an Ethereum transaction TX.

○    Sign the TX with private key (eth_signTransaction)

○    Submit the signed TX to the Ethereum JSON RPC call (eth_sendRawTransaction).

●    Metamask should open automatically to ask the user’s approval.

■   Ask app-specific data analysis questions (in contrast to low level chain-specific

data analysis questions like we did with bitcoin) about the Uniswap pools based  on the Uniswap event data. Use the events emitted by the contracts for the data analysis.

●    Examples:

○    “what are the reserves of the tether-eth pool”

○    “how many swaps have there been so far today”

● Open source LLM:

○    User should have the option to use their own open source LLM. The UI should have a text box that a user can use to specify the URL for an open source model.

○   Your tests should show results on an open source model and OpenAI, side by side.

● Test cases (a.k.a. “test set”, or “task evaluation” in AI):

○   Ten test cases of varying difficulty that show how your system is able to answer natural language questions and follow natural language instructions for Uniswap data.

■    Diversity is critical to the quality of the test suite.

●    Each test case should be significantly different from others.

●    Collectively they should cover the space of possible user NL instructions.

■    Critical for quantifying current level of performance

○   Ten very hard test cases that are so hard that the system is not able to answer correctly. The purpose of this is to find the limit of what’s possible for this task.

■   The test cases should be significantly different from each other.

■    Critical for defining the scope of future improvements.

●    Host your site publicly.

● Prepare an in-class presentation/walkthrough/demo for your UI on the due date.

○ NOTE: The submission will be at midnight, but the demo will be during class earlier that day.

Deliverable

1.    A publicly hosted URL to your UI that achieves the goals above.

2.    Code repo

3.    An “task evaluation” page in your UI that enables execution of your twenty test cases.

a.    For each test case:

i.       The natural language instruction

ii.       The correct answer for the test case.

iii.       A button that executes the test case.

iv.       The output from an open source model

v.       The output from OpenAI

b.    This evaluation page should allow users to add more test cases through the UI.

i.       Does not need to be persistent.

Hints

●    Learn about function calling (aka tool use). Consider whether function calling is easier to use than text-to-sql for this application.

●    Open source models may not work as well as OpenAI out of the box. You may need to try

advanced methods (e.g. chain of thought reasoning, etc) to get open source models to perform. well for this task.

●    Focus on getting your system working end-to-end first before making it better and more

accurate. Think about how to structure your work so that you can link all the pieces together with minimal effort.

○    For example:

■    Figure out how to get your system working for just one simple test case using only OpenAI:

●    “swap 10 USDC for eth”

■    Deploy your system to a public URL.

■    Now you have a minimal working system and now it's easier to back and focus on making each part better (e.g. adding open source models).

Guidelines

●   You may use any UI framework or library.

●   You may write a server for making the LLM calls, if you prefer, instead of doing it in the UI.

Function Calling Example

OpenAI’s response:

[ChatCompletionMessageToolCall (id= 'call_QahB4aCsj8i4veQROOIio2Q4 ', function=Function (arguments= '{"location":"Paris, France"} ',

name= 'get_weather '), type= 'function ')]

Means that OpenAI is telling us to invoke get_weather ( “Paris, France”) in order to get the answer to this question.

Approach

What prompt to use?

Suppose:

User: “swap 10eth for usdc” .

Possible options in increasing levels of accuracy:

1.   The prompt is exactly the instruction from the user.

a.   Example:

i.      Thus, the OpenAI API request would be just:

1.   Message: “swap 10eth for usdc” .

2.   Keep the prompt empty, but also now add a set of tools.

a.   Example:

i.      Message: “swap 10 eth for usdc” .

ii.      Tools:

1. swap (num_tokens_in, in_token_type, out_token_type)

a. in_token_type

i.  description: the name of the token that we are swapping into the AMM.

b. out_token_type

i.  description: the name of the token that we are swapping out of the AMM.

Issue to address:

●   The tool calling gives you the symbols or the names for the tokens, but the Uniswap function actually needs addresses.

●    Converting the tool call function signature into the actual Uniswap call:

○    UniswapRouter.swapExactTokensForTokens (

■    uint amountIn,

■    uint amountOutMin,

■    address [] calldata path,

■    address to,

■    uint deadline)

○    UniswapRouter has many different swap functions. We don’t need to use all of them.

■    We can just pick one.

○   This function is part of the UniswapRouter (not the UniswapPair)

■    UniswapPair has low-level interface to the AMM

●    Expects several setup activities before the call actually works.

■    UniswapRouter does this setup for us.

○   The amountIn parameter is straightforward -- just copy value from tool call.

○   The amountOutMin can be hardwired to 0, which means no constraint how many token we get back.

■   Alternative, adjust tool call signature to mirror exactly the swapExactTokensForTokens signature.

○   A more interesting approach is to:

■ Aspirational: Write general purpose code to convert an ABI json for a contract, into the json schema tool call Open API expects.

●    Part that needs some creativity: where to get the descriptions for the parameters of functions specified in the ABI.

○    One option: give the json schema with empty descriptions to the LLM and ask it to fill it in based on its knowledge.

■    Can increase chance of success:

●    In the prompt we can give it the Solidity contract

○   Through code understanding, it may get some descriptions more accurately than if it just relied on its own internal knowledge

○   Through embedded comments in the Solidity contracts.

●    Question: where to do the LLM call?

○    Ideally in the browser, because it says more decentralized.

○    But there are advantages to doing it server side,especially if you are building a product:

■    But can also just send logs back of user actions to address this. ○ https://webllm.mlc.ai/

■    In-browser inference (as opposed to in-browser API call)

■   App remains truly decentralized

■    Hard part:

●    May not work for cpu, in which you can default to API call

●    even tho if they do have the gpu, may not be powerful enough or fast enough for the types of prompts we have.

●   the main issue is GPU memory. To host powerful models, you need a lot of GPU memory. Otherwise you are limited to small models.

○    Microsoft has Phi series specifically for running smaller models.

●    Sending the transaction (already did this step in hw6)

○    Now we have the solidity function call, we can create a transaction using web3 library, which can then also be used to:

■    Sign the TX with private key (eth_signTransaction,

■    Submit the signed TX to the Ethereum JSON RPC call (eth_sendRawTransaction).

●    Data analysis questions

○    Option #1: Ask OpenAI the question from the user directly.

○    Option #2: One way: same text-to-sql setup, but for event (log) data from Uniswap contracts.

■    “emit *” writes easy to process logs on different action performed on Uniswap (e.g. swaps, deposit, etcs)

■    Read these events through the RPC json for ethereum for uniswap contracts and store them into sqlite

○    Option #3:  Just give OpenAI the eth_getLogs directly and have it write code to call eth_getLogs

○    Option #4: Option #3, but help it with the decoding process.

Example RPC call:

{

"jsonrpc": "2.0", "id": 0,

"method": "eth_getLogs", "params": [

{

"fromBlock": "0x429d3b",

"toBlock": "0x429d3b",

"address": "0xb59f67a8bff5d8cd03f6ac17265c550ed8f33907",

"topics": [

"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",

"0x00000000000000000000000000b46c2526e227482e2ebb8f4c69e4674d262e75",

"0x00000000000000000000000054a2d42a40f51259dedd1978f6c118a0f0eff078"

]

}

]

}

Decoding eth_getLogs into Solidity

Note: return data from eth_getLogs hasn’t been decoded into Solidity concepts. Will need to do that to

decode these bytes into higher level concepts such as:

emit Mint(msg.sender, amount0, amount1);

How can we do this decoding?

Option 1: Ask OpenAI. It may have learned how to decode from examples on the Internet.

Option 2: Ask OpenAI to write code to decode it.

Give it the Solidity contract and the json rpc call.

Option 3: Find an existing library to do the decoding.

Next issue: how to convert natural language instruction into code that calls our tools.

Ask OpenAI: answer the user’s  data analysis question about Uniswap. The question is at the bottom of this prompt. Write code to You may use these functions to do, assume they’ve been implemented.

To-do:

●    Check why the enum validation in the schema wasn’t honored by OpenAI tool calling