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
+30-33Lines changed: 30 additions & 33 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,25 +11,16 @@ Instead we create a pool, where the owners are asked to each rank the tokens in
11
11
The [wikipedia article](https://en.wikipedia.org/wiki/Top_trading_cycle) does a good job explaining what the algorithm and setting is, and hints at various generalizations with links in the footnotes.
12
12
13
13
## Architecture
14
-
1. A Solidity smart contract capabale of
15
-
- holding NFTs in a custodial mannor (ideally with safe retrieval in case the participant wants to exit before completion)
16
-
- accepting trading preferences
17
-
- "locking down" for a period of time long enough to execute the trading algorithm off chain
18
-
- accepting and validating proofs for the results of the trading algorithm (a "re-allocation")
19
-
- allowing users to withdraw according to re-allocation
20
-
2. A rust implementation of the Top Trading Cycle (TTC) algorithm, and a compatibility layer for inputs/outputs expected by the contract.
21
-
3. Risc-Zero zkvm + [Steel](https://github.com/risc0/risc0-ethereum/tree/main/crates/steel) for generating Groth16 proofs of the TTC execution on smart contract data.
22
-
4. TODO: A server to monitor the contracts for proof requests / callbacks, and a gpu accelerated environment to construct the proofs.
23
-
5. TODO: A simple UI + testnet deployment for illustration purposes.
14
+
For architecture diagrams, see [here](./docs/README.md#architecture-diagram). For more details on the flows and service interaction, see [here](./docs/README.md#flows)
24
15
25
-
## Test against local node
26
-
The `host` crate contains an end-to-end test using a randomly generated allocation. See the [node_test](https://github.com/l-adic/ttc/blob/main/.github/workflows/node_test.yml) workflow for how you would set these up and run locally.
16
+
## Development Environment Setup
27
17
28
-
## Development Environment
29
-
30
-
### Development Environment Setup
18
+
Two tmuxinator configurations are provided for development. Both configurations set up:
19
+
- Ethereum node and Postgres
20
+
- Prover and Monitor servers
21
+
- System monitoring (e.g htop, nvidia-smi)
22
+
- Command shell
31
23
32
-
Two tmuxinator configurations are provided for development:
33
24
34
25
#### 1. Local Development (`.tmuxinator.yml`)
35
26
Run services locally with cargo:
@@ -43,25 +34,31 @@ Run all services in Docker containers:
43
34
tmuxinator start -p .tmuxinator.docker.yml
44
35
```
45
36
46
-
The Docker configuration automatically rebuilds the prover-server and monitor-server images before starting to ensure they reflect your current code. This is important when you've made changes to:
47
-
- Any Rust source files
48
-
- Cargo.toml dependencies
49
-
- Dockerfile configurations
37
+
## Testing
38
+
The `host` crate contains an end-to-end test using a randomly generated allocation. You can check the corresponding [github workflow](./.github/workflows/node_test.yml) for reference,
39
+
and view the [Makefile](./Makefile) for a complete set of config options
40
+
41
+
1. Deploy the services (see [above](./README.md#development-environment-setup)) or use a hosted deployment.
42
+
43
+
2. You must fetch the `ImageID.sol` contract and store it in the correct location. This contract is what cryptographically binds the solidity verifier to the rust TTC program.
50
44
51
-
If you need to manually rebuild the images:
52
45
```bash
53
-
docker compose build prover-server monitor-server
46
+
> make fetch-image-id-contract > contract/src/ImageID.sol
54
47
```
55
48
56
-
Both configurations set up:
57
-
- Ethereum node and Postgres logs
58
-
- Prover and Monitor servers
59
-
- System monitoring (htop)
60
-
- Command shell
49
+
3. Deploy the contracts:
50
+
51
+
```
52
+
> make deploy
53
+
```
54
+
NOTE: use the `deploy-mock` variant if you are running a mock verifier (recommended if you aren't using a cuda accelerated prover).
55
+
You should see the deploy address of the TTC contract printed to the console. There will be a json artifact written to `./deployments/<ttc-contract-address>/deployed.json`
56
+
57
+
4. Run the demo script with the desired config options, e.g.
58
+
59
+
```
60
+
> TTC_ADDRESS=<ttc-contract-address> NUM_ACTORS=10 PROVER_TIMEOUT=600 make run-node-tests
61
+
```
61
62
62
-
#### Tmux Key Bindings
63
-
- Exit/detach from tmux: `Ctrl-b d`
64
-
- Switch between windows: `Ctrl-b [0-9]` or mouse click
65
-
- Switch between panes: `Ctrl-b arrow` or mouse click
66
-
- Scroll in a pane: Mouse wheel or `Ctrl-b [` then arrow keys (press `q` to exit scroll mode)
67
-
- Copy text: Select with mouse (may need to hold Shift depending on your terminal)
63
+
You can control the log level via `RUST_LOG`. This script creates checkpoints, writing the relevant state to `./deployments/<ttc-contract-address>`. If the script errors or halts at any
64
+
time, you can re-run from the last checkpoint using the same command as you used to start.
0 commit comments