-
Notifications
You must be signed in to change notification settings - Fork 170
Peggy & Peggo Testing
This document outlines a high level overview of testing the integration of Peggy, the Gravity Bridge variant by InjectiveLabs, and Peggo, the Golang-based Peggy orchestrator.
We'll outline this document in three core areas:
- Bootstrapping the network as a validator
- Joining an already bootstrapped network
- A general FAQ
NOTE: Peggy was forked from InjectiveLabs and is still under heavy development and refactoring. CLI arguments and other logic is subject to change.
-
Install the latest v0.5.x version of
umeed
(v0.5.0-rc2
). -
Install the latest version of Peggo via
$ make install
(v0.1.0
) -
Ensure you have the following:
- A connection to a Goerli Ethereum RPC node (e.g. https://goerli.infura.io/v3/c51fbdff84f24055a2e003d2389466c5)
- A Goerli Ethereum account and the associated private key (in HEX)
- A
umeed
keyring setup with an account that will operate as the validator operator.
-
A designated coordinator must deploy the Peggy contract:
$ peggo bridge deploy-peggy --eth-pk=$ETH_PK --eth-rpc=$ETH_RPC
-
Observe the output of the previous command. It will display the Ethereum transaction and the Peggy contract address. Wait until the Ethereum transaction is committed and observe the height at which it was committed.
-
Once the Peggy transaction is committed, the designated coordinator updates or creates the Umee genesis file. In the context of Peggy, the following fields should be populated:
"params": { "bridge_ethereum_address": "...", "bridge_contract_start_height": "...", "bridge_chain_id": "" }
-
Once the Umee genesis file is finalized. The Umee chain can start.
-
After starting the Umee chain, each bootstrapping validator must register their Ethereum key (notice this used to be
peggo tx register-eth-key
):umeed tx peggy set-orchestrator-address \ {validatorAddress} \ {validatorAddress} \ {ethAddress} \ --eth-priv-key=$ETH_PK \ --chain-id="..." \ --fees="..." \ --keyring-backend=... \ --keyring-dir=... \ --from=...
-
Once each validator has registered their Ethereum key, the designated coordinator must initialize the Peggy contract:
$ peggo bridge init-peggy --eth-pk=$ETH_PK --eth-rpc=$ETH_RPC
-
At this point, each validator can start their Peggo orchestrator process:
--coingecko-api="https://peggo-fakex-qhcqt.ondigitalocean.app/api/v3"
Peggo now has the ability to listen to transactions in the "pending transaction
queue" and avoid sending a TX containing the same data (invalid transactions).
You can get an API key for free at Alchemy. Please make sure
that you are using the flag --eth-alchemy-ws=
.
$ peggo orchestrator \
--eth-pk=$ETH_PK \
--eth-rpc=$ETH_RPC \
--relay-batches=true \
--relay-valsets=true \
--cosmos-chain-id=... \
--cosmos-grpc="tcp://..." \
--tendermint-rpc="http://..." \
--cosmos-keyring=... \
--cosmos-keyring-dir=... \
--cosmos-from=... \
--coingecko-api="https://peggo-fakex-qhcqt.ondigitalocean.app/api/v3" \
--profit-multiplier=1.0 \
--eth-alchemy-ws="wss://eth-goerli.alchemyapi.io/v2/YOUR_ALCHEMY_APIKEY"
Assuming a network has already been bootstrapped and you've already created your validator, you only need to register your Ethereum key and start the Peggo orchestrator. Perform steps (9) and (11) from above.
Peggo should notice changes in the validator set and relay these to the Peggy contract on Ethereum.
-
Can any Cosmos naive or Ethereum ERC20 token be transferred?
⚠️ At the moment only a subset of tokens is approved, any others might get stuck in Umee.Yes, but the Peggy module must be initialized first. Please see the note from the bootstrapping section. Once this happens, any ERC20 can be transferred to and from Umee.
See
$ peggo bridge send-to-cosmos --help
for help on how to send tokens from Ethereum to Cosmos.Any Cosmos native can be transferred to and from Ethereum, but the Cosmos native asset must be first deployed as an ERC20.
See
$ umeed tx peggy send-to-eth --help
for help on how to send tokens from Cosmos to Ethereum.