You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+40-64Lines changed: 40 additions & 64 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@
20
20
21
21
It is built for developing, testing, and debugging Soroban contracts locally, and adds two capabilities a public Stellar network does not offer:
22
22
23
-
-**Instruction-level traces.**The `traceTransaction` method runs a transaction and returns a step-by-step record of every WebAssembly instruction the contract executed, so you can see exactly what happened — and where it went wrong.
23
+
-**Instruction-level traces.**Every transaction is traced as it runs, and the `traceTransaction` method returns that step-by-step record of every WebAssembly instruction the contract executed, so you can see exactly what happened — and where it went wrong.
24
24
-**Reproducible, replayable state.** The ledger state is persisted to disk, so you can stop and restart the node, save a state, and replay transactions against it to reproduce a result.
25
25
26
26
## 🚀 Quick Start
@@ -66,63 +66,41 @@ docker run --rm -p 8000:8000 \
66
66
67
67
#### Start the server
68
68
69
-
```bash
70
-
komet-node # serve on localhost:8000, state in ./state.kore
71
-
komet-node --help # print general usage information
Komet Node — a local Stellar testnet backed by the K semantics of Soroban.
75
+
76
+
options:
77
+
-h, --help show this help message and exit
78
+
--host HOST bind address (default: localhost)
79
+
--port PORT port to listen on (default: 8000)
80
+
--io-dir IO_DIR directory for all input/output artifacts (default: a fresh
81
+
temporary directory)
82
+
83
+
examples:
84
+
komet-node serve on localhost:8000 in a fresh temp dir
85
+
komet-node --port 9000 use a custom port
86
+
komet-node --io-dir ./chain keep all artifacts under ./chain (persistent)
87
+
komet-node --host 0.0.0.0 accept connections from outside localhost
74
88
```
75
89
76
-
| Flag | Default | Description |
77
-
|---|---|---|
78
-
|`--host`|`localhost`| Bind address |
79
-
|`--port`|`8000`| Port to listen on |
80
-
|`--state-file`|`state.kore`| Path to the persistent state file |
81
-
|`--trace`| off | Enable instruction-level execution tracing |
90
+
#### Trace a transaction
82
91
83
-
On first start the server creates `state.kore` in the state file's directory — along with two small bookkeeping files, `metadata.json` and `transactions.json` — and begins from an empty chain. The state persists across restarts, so stopping and restarting the node resumes the same chain. To start over from an empty chain, delete `state.kore`; to resume from a chain you saved earlier, point `--state-file` at it.
92
+
Every submitted transaction is traced as it executes, and the instruction-level trace is stored on its receipt. `traceTransaction` retrieves that stored trace, looked up by transaction hash — the same hash `getTransaction` takes. So tracing a contract invocation is two calls: `sendTransaction` to run it, then `traceTransaction` with the returned hash. Tracing is always on; there is no flag to enable.
84
93
85
-
#### Verify the server with `curl`
94
+
Submitting transactions uses the standard two-step Stellar pattern — `sendTransaction`with a base64 XDR envelope, then poll `getTransaction` by hash. Because there is no mempool, `komet-node` executes the transaction synchronously inside `sendTransaction`, so the result is already available by the time you poll. See [docs/server.md](docs/server.md) for the full RPC reference.
86
95
87
-
The server is operated via the Stellar RPC protocol. The read-only methods below take no transaction payload and can be used as a quick health check:
96
+
A trace requires a deployed contract. The four envelopes below are pre-built and signed (a tiny contract whose `foo()` returns void, deployed from a fixed key) so you can paste them straight in — the local node does not check signatures, sequence numbers, or timebounds, so they work as-is on a fresh chain. After a quick health check, run them in order against the server started above.
Submitting transactions uses the standard two-step Stellar pattern — `sendTransaction` with a base64 XDR envelope, then poll `getTransaction` by hash. Because there is no mempool, `komet-node` executes the transaction synchronously inside `sendTransaction`, so the result is already available by the time you poll. The trace example below shows this flow end-to-end with ready-to-run envelopes; see [docs/server.md](docs/server.md) for the full RPC reference.
114
-
115
-
#### Trace a transaction
116
-
117
-
`traceTransaction` executes a transaction and returns an instruction-level execution trace inline, in a single call. Tracing only applies to contract invocations, so the server must be started with `--trace`:
118
-
119
-
```bash
120
-
komet-node --trace
121
-
```
122
-
123
-
A trace requires a deployed contract. The four envelopes below are pre-built and signed (a tiny contract whose `foo()` returns void, deployed from a fixed key) so you can paste them straight in — the local node does not check signatures, sequence numbers, or timebounds, so they work as-is on a fresh chain. Run them in order against the server above.
The final call returns the result inline. The `trace` field is itself a JSONL string (one JSON record per executed WebAssembly instruction); it is shown decoded here for readability:
126
+
`traceTransaction`returns the stored trace as its result. The trace is a JSONL string (one JSON record per executed WebAssembly instruction); it is shown decoded here for readability:
0 commit comments