Reading Confirmations from the Espresso Network
Last updated
Last updated
This guide introduces a Go project that reads from the Espresso Network and monitors for specific transactions, filtering them by value and sender address. You can imagine this project as being a bot that alerts you when your wallet gets drained.
The hackathon-example provides a foundation for building applications that interact with the Espresso Network. You can use this project as a starting point for developing applications or more sophisticated monitoring and analysis tools.
Before proceeding with this guide, you'll need:
A running Arbitrum Orbit chain integrated with the Espresso Network, either locally or in the cloud
Access to a Caffeinated node, which serves as your interface to the Espresso Network
For convenience, the Caffeinated node setup is available in the same espresso-build-something-real as the previous guide, under the caff-node directory. If you've already deployed your rollup following the earlier instructions, you're ready to proceed with this monitoring project.
The Caffeinated node is a full node and your interface to the Espresso Network. It processes Hotshot blocks, maintains state, and provides a JSON-RPC endpoint for monitoring transactions. The monitoring tool we'll build uses these capabilities to track specific transactions based on sender address and value.
Navigate to the repository and follow these steps to configure and run your caffeinated node locally:
Update the caff-node/config/caff_node.json file with:
Namespace and Chain ID: Both should match your rollup chain ID. Update both values.
Next Hotshot Block:
Find the latest Hotshot block height at https://explorer.decaf.testnet.espresso.network/. Update this value just before running the Caffeinated node to avoid resyncing the entire chain.
Parent Chain Node URL: Enter your Arbitrum Sepolia or mainnet RPC URL (must be a WebSocket URL).
📝 Note: We recommend using a different RPC URL for the caff node to avoid hitting rate limits (free tier should be enough).
Copy Configuration Files:
Copy the l2_chain_info.json file into the caff-node/config folder
Copy the database folder from the repository root to the caff-node directory.
📝 Note: Make sure the node is not running when you do this.
Start the Services:
First, run docker compose up at the root of the repository.
Then, run docker compose up in the caff-node folder.
Clone the Repository
If you've already cloned the repository without the --recursive flag (e.g., through your IDE), you can fetch the go-ethereum submodule with:
The reason we are doing this is because we want to use a forked version of the go-ethereum library from offchainlabs to interact with the caffeinated node.
Install Dependencies
Configure the Application
You should configure the following settings in the /config/config.json file:
caff_node_url: Change YOUR_HOST to either:
localhost if running locally.
Your EC2 instance's IPv4 address if running on the cloud.
polling_interval:
Controls how frequently the application checks for new transactions.
Adjust based on your needs, but keep it low enough to avoid missing transactions.
value: Set the minimum transaction value (in wei) that you want to monitor.
from: Enter the Ethereum address you want to monitor transactions from.
📝 Note: The docker setup exposes the Caffeinated node on port 8550. 📝 Note: The code divides the polling value by 2 to determine the actual polling interval.
Run the Application At the root of the repository, run the following command:
This will start the application and monitor the Espresso Network for transactions that match your rollup and the specified criteria.
📝 Note: This monitoring tool simply logs matching transactions to the console. You can extend it to perform more complex actions when transactions are detected.
Send Transactions
Now that you have both your rollup and Caffeinated node running, you can send test transactions to your rollup. You have two options:
Use a simple command-line transaction:
These transactions will be processed by your rollup and should appear in the monitoring tool's output if they match your configured criteria.
📝 Note: The block number shown in the logs is not the latest block height of the espresso network but the latest block processed by your rollup.
If you've followed the guide carefully and paid attention to the notes, you shouldn't encounter many issues. However, here are solutions to some common problems:
The following logs are normal and not cause for concern:
These messages simply indicate that the node is listening to the rollup but there are no new transactions to process.
The following logs indicate that the node is correctly listening to the rollup and has detected a new transaction:
If you see many logs like these at startup, your Caffeinated node is simply syncing to the latest Hotshot block:
If you stop and restart both your rollup and Caffeinated node, you might need to recopy the database folder to your /caff-node folder. Failing to do this can cause your rollup and Caffeinated node to fall out of sync.
📝 Note: This can result in transactions not being detected by the monitoring tool.
If you're experiencing rate limiting from your RPC provider, you can adjust polling intervals in the configuration files:
Increasing these intervals will reduce the frequency of RPC calls, helping you stay within rate limits.
If you don't see logs indicating successful block processing, your Caffeinate node might not be properly connected to or in sync with the rollup. This often happens when the database directory isn't properly configured. You should see logs like:
If these logs are missing, check that:
Your repository structure is correct.
The docker-compose.yml file is properly configured and indented.
Your caffeinated node is properly syncing with the rollup.
Update Caffeinated Node Configuration: In caff-node/config/caff_node.json, update the following values:
📝 Note: Make sure to use a WebSocket URL (starting with
wss://) for your Arbitrum mainnet RPC provider.
Create and configure the caff-node directory structure on your EC2 instance:
📝 Note:
The
configdirectory remains owned by ec2-user for configuration files
databaseandwasmdirectories need write permissions for the Docker container user (1000:1000)
Transfer the config files to your EC2 instance: From the root of the repository, run the following command:
Copy the database from your rollup to the caff-node directory: From outside the EC2 instance, run the following command:
Or from inside the EC2 instance, run the following command:
📝 Note: Make sure you sync and stop the rollup service before copying the database. This step is crucial and is often the cause of issues.
Enable CloudWatch Logging (Optional):
If you want to monitor your caffeinated node logs in CloudWatch:
Modify your caff-node/docker-compose.yml file to include CloudWatch logging:
📝 Note: Make sure to update the
awslogs-regionto match your EC2 instance's region.
Whether you enabled logging or not, you can now transfer the docker-compose.yml file inside your instance. From outside the EC2 instance, run the following command:
Connect to your EC2 instance and start the services:
Once your caffeinated node is running on the cloud, update the caff_node_url in the hackathon-example repository's config to point to your EC2 instance's public IP address. Then try running the application with the updated config.
Configuring Network Access
If you encounter connection timeouts when trying to access your EC2 instance (e.g., dial tcp YOUR_HOST:8550: i/o timeout), you need to open the required ports in your EC2 security group:
In the AWS EC2 Console, navigate to your instance
Select the "Security" tab in the bottom panel
Click on the security group ID (e.g., "sg-0123456789abcdef")
In the security group page, select the "Inbound rules" tab
Click "Edit inbound rules"
Add two new rules:
Type: Custom TCP, Port range: 8547, Source: Custom 0.0.0.0/0 (or your IP for better security)
Type: Custom TCP, Port range: 8550, Source: Custom 0.0.0.0/0 (or your IP for better security)
Click "Save rules"
This enables external connections to your Caffeinated node (port 8550) and rollup node (port 8547).
Instructions can be found on the to set this project up but we will go over the steps here in more detail.
Use the transaction generator script in the espresso-build-something-real/tx-generator directory, which can continuously generate test transactions. See the in that repository for detailed instructions.
Solution: To reduce syncing time, update the next-hotshot-block value in caff-node/config/caff_node.json to the latest block height from the before starting the node.
To ensure your setup is ready for Arbitrum and Espresso mainnet, you'll need to make the following changes in addition to those described in the Deploying Your Rollup on Mainnet in the previous guide:
Update Hotshot Block Height: Find the latest Hotshot block height at the and update the next-hotshot-block value in your configuration.
Similarly to the preceding guide, the next step would be to deploy your caffeinated node on the cloud. You can follow the instructions in the Cloud Configuration of the previous guide for building your EC2 instance and installing the required docker configs. Here are the steps to migrate your caffeinated node to the cloud:
Start off from the Set Up and Run of this guide. The steps on how to run your rollup in the cloud have been covered in the previous guide. You can use the same rollup config files.
Create a log group for your caffeinated node in the CloudWatch console, similar to how you created log groups in the Setting up CloudWatch logging of the previous guide.
📝 Note: Your rollup folder structure should be very similar to the repository structure of the espresso-build-something-real . 📝 Note: You can always update the docker-compose.yml file using nano or by copying again the file from the repository.
📝 Note: Do not forget to update the latest hotshot block height in the caff-node/config/caff_node.json from the to avoid resyncing the entire chain. 📝 Note: You can stop the services by running docker compose down in the rollup and caff-node directories. 📝 Note: You can remove the -d flag to run see the logs of the containers in the terminal.