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
The brevis binary and brevis.toml are required to run as an operator. The brevis binary should be run under Linux AMD64 system. It can also be built from source with command: go build -o brevis
Make sure the total stake > 0.01 eth in Eigen Layer, we support same strategies as Eigen DA
Add bls and ecdsa key of Eigenlayer info to the brevis.toml config file, both are required to join Brevis. Also recommend to change ethereum gateway RPC in the config file to a private one
Run brevis join --chainid 1 --quorums 0x01 cmd to opt-in Brevis AVS
Add operator id printed by last brevis join command (bytes32 hex string) to config file, note it's NOT your ETH addr
(optional but recommended): Remove ecdsa key info from config file as it's not needed for normal operation. only bls key is needed
Operator runs brevis run cmd which monitors Brevis contract for new requests, and signs w/ BLS key, then posts to Brevis gateway. Brevis operator process by default uses port 8081 to accept imcoming requests, such as health check. If the port already has been used by other process, please run the cmd with --port param to specify another one
Operator can monitor the process alive by checking api: GET /eigen/node/health, http status 200 means OK
Suggested hardware configuration: AWS C5/C6 2x large equivalent, 500GB disk.
Contact Brevis team for any issue or questions.
Run the binary as a systemd service (optional but recommended)
It is strongly advised to execute the binary in the context of a systemd service, enabling it to operate as a background process or daemon. This configuration ensures that the binary initiates automatically upon system startup or reboot.
Make sure to have followed step 1 to 5 from the Run as an Operator section
Create a new systemd service file using your preferred text editor. For example, using vim:
sudo vim /etc/systemd/system/brevis.service
Add the following content to the brevis.service file. If necessary, adjust the ExecStart and WorkingDirectory paths as well as the User and Group.
[Unit]
Description=Brevis Service
After=network.target
[Service]
User=ubuntu
Group=ubuntu
WorkingDirectory=/home/ubuntu/brevis-avs
ExecStart=/home/ubuntu/brevis-avs/brevis run
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
Reload the systemd manager configuration to read your newly created service file:
sudo systemctl daemon-reload
Enable the service to start at boot:
sudo systemctl enable brevis
Start the service immediately:
sudo systemctl start brevis
To check the status of your service:
sudo systemctl status brevis
To view the logs of your service:
journalctl -u brevis -f
Gateway Functions(Gateway is Run by Brevis Team)
brevis gw cmd, needs a different config eg. gateway.toml
accepts sig requests from eigenlayer operators, aggregate sigs, then send onchain
accepts query requests from eigelayer operators, to query the original request data of a request ID
accepts query requests from user, to query request ID and fee
How the Brevis AVS works
Dev App queries request ID and fee amount from Brevis Gateway for a set of slots, receipts, and transactions from a supported chain to be certified by Brevis AVS. Gateway retrieves the storage slot value, receipt log value, or raw tx data etc from chain RPC node, and generates the request ID, which is a hash of the data. Refer to API Prepare Query.
Dev App then sends a request with the request ID, required fee to the BrevisRequest contract. Refer to BrevisContract.sendRequest. In AVS mode, _callback and _option params are not taking effect.
Gateway monitors the request event emitted by the BrevisRequest contract, checks that the fee is sufficient, and updates the request status to FEE_PAID.
Brevis Operators respectively monitor the request event emitted by the BrevisRequest contract, retrieve the original request info from Brevis Gateway, and recalculate the request ID based on the data onchain. If the request ID matches, then operators respectively sign the request ID and send signature to Brevis Gateway.
The gateway aggregates the signatures after the aggregation task is done, then submits to BrevisEigen contract to check signatures. BrevisEigen will record the verification status. Refer to BrevisEigen contract.
The gateway calls BrevisRequest contract to fulfill the request. BrevisRequest will check with BrevisEigen contract if the request ID is verified, and store the request ID to BrevisProof contract.
Finally, the Brevis App can use the reqeust filled data (Refer to ExtractInfos), if the data hash is the same with the stored request ID in BrevisProof contract. Refer to BrevisApp for an abstract contract that can be inherited by Dev team.