Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a document for espresso-dev-node #1722

Merged
merged 14 commits into from
Jul 31, 2024
71 changes: 71 additions & 0 deletions doc/espresso-dev-node.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
# Espresso Dev Node

Espresso dev node is a node specifically designed for development and testing. It includes various nodes required to run
a complete Espresso network, such as `builder`, `sequencer`, etc. Developers can use it for development and testing.

## Download

We highly recommend you to use our Docker image. You can run it from the command line:

```cmd
docker run ghcr.io/espressosystems/espresso-sequencer/espresso-dev-node:main
```

## Parameters

| Name | Type | Environment Variable | Default Value | Description |
| ------------------------------- | --------------- | ------------------------------------ | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| `rpc_url` | `Option<Url>` | `ESPRESSO_SEQUENCER_L1_PROVIDER` | Automatically launched Avil node if not provided. | A JSON-RPC endpoint for the L1 to deploy to. If not provided, an Avil node will be launched automatically. |
ImJeremyHe marked this conversation as resolved.
Show resolved Hide resolved
| `mnemonic` | `String` | `ESPRESSO_SEQUENCER_ETH_MNEMONIC` | `test test test test test test test test test test test junk` | Mnemonic for an L1 wallet. This wallet is used to deploy the contracts, so the account indicated by `ACCOUNT_INDEX` must be funded with ETH. |
| `account_index` | `u32` | `ESPRESSO_DEPLOYER_ACCOUNT_INDEX` | `0` | Account index in the L1 wallet generated by `MNEMONIC` to use when deploying the contracts. |
ImJeremyHe marked this conversation as resolved.
Show resolved Hide resolved
| `sequencer_api_port` | `u16` | `ESPRESSO_SEQUENCER_API_PORT` | Required | Port that the HTTP API will use. |
| `sequencer_api_max_connections` | `Option<usize>` | `ESPRESSO_SEQUENCER_MAX_CONNECTIONS` | None | Maximum concurrent connections allowed by the HTTP API server. |
| `builder_port` | `Option<u16>` | `ESPRESSO_BUILDER_PORT` | An unused port | Port for connecting to the builder. |
| `prover_port` | `Option<u16>` | `ESPRESSO_PROVER_PORT` | An unused port | Port for connecting to the prover. If this is not provided, an available port will be selected. |
| `dev_node_port` | `u16` | `ESPRESSO_DEV_NODE_PORT` | `20000` | Port for the dev node. This is used to provide tools and information to facilitate developers debugging. |

## APIs

Once you have successfully run the dev node, you can access the corresponding ports to call the APIs of the
[`builder`](https://docs.espressosys.com/sequencer/api-reference/builder-api),
[`sequencer`](https://docs.espressosys.com/sequencer/api-reference/sequencer-api), and `prover`.

In addition, you can access the `dev_node_port` to retrieve debugging information. Here are the details of the dev node
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider linking to the toml specification or generated docs (if we generate documentation from the specification).

Copy link
Member Author

@ImJeremyHe ImJeremyHe Jul 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The toml specification is used to generate an HTML doc for users accessing to a wrong route/endpoint. Of course we can also link the toml file here, but just a bit weird. And builder api page doesn't link anything, so I just followed the conventions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

builder api documentation should also link to spec 😃 (IMO) .

API.

### GET /api/dev-info

This endpoint returns some debug information for you.

An example response is like this:

```json
{
"builder_url": "http://localhost:41003/",
"prover_port": 23156,
"l1_url": "http://localhost:8545/",
"light_client_address": "0xb075b82c7a23e0994df4793422a1f03dbcf9136f"
}
```

### POST /api/set-hotshot-down

This endpoint simulates the effect of a liveness failure of the hotshot consensus protocol in the Light Client smart
contract.

By calling this, the L1 height in the light contract will be frozen, and rollups will detect the HotShot failure. This
is intended for testing rollups' functionalities when HotShot is down.

Parameters
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming these parameters are set in the POST body, but I don't see this stipulated anywhere. I think it could be helpful to show an example request with curl which shows exactly what the request looks like.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


| Name | Type | Description |
| ------ | ------- | ---------------------------------------- |
| height | integer | The L1 height from which hotshot is down |

### POST /api/set-hotshot-up
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious if we really need both endpoints. could we just have post /api/hotshot or similar which which reacted on the basis of current state of hotshot (like a toggle). Also since these are POSTs, it might be reasonable to move the command to the POST body. just a thought

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that makes sense. I don't have any though about which is better. But the parameters of these 2 endpoints are totally different. I think we don't have to combine these into only 1.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Humm yea but it is POST, so if we do something like RPC we could just have a command input, and the request bodies would all differ based on the command. But anyway it not really import


This endpoint simulates the effect of a liveness success of the hotshot consensus protocol in the Light Client smart
contract.

This is intended to be used when `set-hotshot-down` has been called previously. By calling this, rollups will detect the
reactivity of HotShot.
6 changes: 5 additions & 1 deletion scripts/launch-dev-node-with-postgres
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,9 @@ export POSTGRES_PASSWORD=$ESPRESSO_SEQUENCER_POSTGRES_PASSWORD

export RUST_LOG=${RUST_LOG:-info}

# Trap SIGTERM and SIGINT signals and send them to the process group
trap "trap - SIGTERM && kill -- -$$" SIGINT SIGTERM EXIT

# Start postgres in the background
docker-entrypoint.sh postgres &

Expand All @@ -22,4 +25,5 @@ until pg_isready && sleep 1 && pg_isready; do
done

# Start the dev node
espresso-dev-node
espresso-dev-node &
wait
2 changes: 1 addition & 1 deletion sequencer/api/espresso_dev_node.toml
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,6 @@ METHOD = "POST"
DOC = """
Set the hotshot up in the light client contract.

This is intended to be used when `freeze` has been called previously. By unfreezing the L1 height,
This is intended to be used when `set-hotshot-down` has been called previously. By calling this,
rollups will detect the reactivity of HotShot.
"""
Loading