Added query_account entrypoint using soroban-rs in WASI component

Author: merkle-maren

Cargo.lock

@@ -0,0 +1,41 @@
+# Stellar RPC in WASI: jsonrpsee version mismatch
+
+## Problem
+
+`soroban-rs` (0.2.6) depends on `stellar-rpc-client` which requires `jsonrpsee-http-client ^0.20.1`.
+Even the latest `stellar-rpc-client` (25.1.0) still pins jsonrpsee 0.20.
+
+Our wasip2 fork is based on jsonrpsee 0.26 (hyper 1.x). `[patch.crates-io]` cannot substitute
+0.26 for a `^0.20.1` requirement — semver mismatch.
+
+## Options
+
+### 1. Fork jsonrpsee 0.20 with wasip2 changes
+
+Port the `WasiConnector` and `DirectResolver` changes to jsonrpsee 0.20, which uses hyper 0.14
+(completely different client API from hyper 1.x). The connector and TLS plumbing would need to be
+rewritten for the older hyper API. More work, but soroban-rs and stellar-rpc-client stay unchanged.
+
+**Pros:** No other forks needed, `[patch.crates-io]` works directly.
+**Cons:** Maintaining wasip2 patches across two major jsonrpsee versions (0.20 and 0.26).
+
+### 2. Raw JSON-RPC calls via existing hyper client
+
+Skip soroban-rs in the wasi component entirely. Use our working `http.rs` helper (hyper 1.x +
+tokio TcpStream + std::net DNS) to make raw JSON-RPC POST requests. The Stellar RPC methods
+(`getHealth`, `getLedgerEntries`, `getAccount`) are simple JSON-RPC — just POST JSON and parse
+the response. XDR decoding can use `stellar-xdr` directly (pure Rust, no networking).
+
+**Pros:** No additional forks. Uses the stack we already proved works. Minimal dependencies.
+**Cons:** No type-safe RPC client. Must manually construct JSON-RPC request/response envelopes.
+Duplicates some logic from stellar-rpc-client.
+
+### 3. Fork soroban-rs + stellar-rpc-client to use jsonrpsee 0.26
+
+Fork both crates to upgrade their jsonrpsee dependency from 0.20 to 0.26. This involves updating
+all jsonrpsee API call sites in stellar-rpc-client (the API changed significantly between 0.20 and
+0.26). Then use `[patch.crates-io]` to point jsonrpsee 0.26 at our wasip2-tls fork.
+
+**Pros:** Full type-safe client. Uses our existing jsonrpsee 0.26 wasip2 fork.
+**Cons:** Most forks to maintain (soroban-rs, stellar-rpc-client, jsonrpsee). Breaking API changes
+between jsonrpsee 0.20 and 0.26 make the stellar-rpc-client port non-trivial.

client/wasi/STELLAR.md

@@ -7,3 +7,4 @@ edition = "2024"
 wasmtime = { version = "29", features = ["component-model"] }
 wasmtime-wasi = "29"
 anyhow = "1"
+dotenv = "0.15"

client/wasi/wasi-runner/Cargo.toml

@@ -23,6 +23,8 @@ impl WasiView for State {
 }
 
 fn main() -> Result<()> {
+    dotenv::dotenv().ok();
+
     let arg = std::env::args().nth(1).unwrap_or_default();
 
     let mut config = Config::new();
@@ -52,8 +54,15 @@ fn main() -> Result<()> {
 
     let result = match arg.as_str() {
         "health" | "" => instance.call_get_health(&mut store)?,
+        "account" => {
+            let rpc_url = std::env::var("XLM_RPC_URL")
+                .expect("XLM_RPC_URL must be set in .env or environment");
+            let account_id = std::env::var("XLM_ACCOUNT")
+                .expect("XLM_ACCOUNT must be set in .env or environment");
+            instance.call_query_account(&mut store, &rpc_url, &account_id)?
+        }
         id => {
-            let id: u32 = id.parse().expect("argument must be a number or 'health'");
+            let id: u32 = id.parse().expect("argument must be a number, 'health', or 'account'");
             instance.call_get_data(&mut store, id)?
         }
     };