The purpose of the explorer is to help users interact with the blockchain:
- Sign up to participate in devnet
- Create accounts (public/private key pairs)
- Ask the faucet for tokens on devnet
- Explore the block DAG
- Deploy contracts
After cloning the repo cd
to the root of the clarity dir and run:
yarn install // Installs dependencies
yarn build // Builds components from packages
You should then spin up an nctl network of nodes locally to run Clarity against.
Now that the packages and network are ready you will need 3 terminals to get it all working:
// Terminal A
cd packages/event_store
rm development_sqlite.db // Wipe old data
npm run start-web-server // Start event-store
// Terminal B
npm run start-event-handler // Start processing event-stream
// Terminal C
cd ../../
yarn dev // Start local Clarity instance
If you want to run the Cypress test suite you will then need one more terminal and run one of the following:
yarn cypress:dev // Opens the Cypress GUI and holds the test window open on
completion of the suite.
yarn cypress:chrome // Runs the Cypress tests and closes the browser on completion,
results are printed to the terminal.
To package the whole thing into a docker image, run docker-build/clarity
in the project root directory.
To test the faucet we need the node running and ready to accept deploys. We also have to fund it with initial tokens and send one deploy in the name of the genesis account which will transfer funds to the faucet.
We can use the contracts/transfer
to donate the initial amount of funds to the faucet. Contracts will be built together with the docker image, but you can build them separately by running make .make/explorer/contracts
in the top level directory.
Start a local docker network first:
cd ../hack/docker
make up node-0/up
cd -
Start the server
in one console:
cd server
npm run dev
and the ui
in another one:
cd ui
npm start
A new browser window will automatically open pointing at the app running at http://localhost:8000
The server should serve the config that will route traffic to the grpcwebproxy
container running in Docker, while we can work on the UI and see it reload after each change. Check out the server
README for details about how it can be configured to tell the UI to connect to a remote server like devnet.
If we were not using the faucet-account
that's created in the hack/docker
setup as the Faucet account, we'd have to establish the an account by transfering some tokens to it that it can later pass on. Here's how to do it:
Generate the necessary contracts first:
cd .. ; make build-explorer-contracts ; cd -
The server
component has a utility program to do the initial token transfer, let's build that first (not necessary if we already built everything with docker):
cd server ; npm run build ; cd -
Run the transfer from the genesis account to our test faucet account.
node ./server/dist/transfer.js \
--host-url http://localhost:8401 \
--transfer-contract-path contracts/transfer_to_account_u512.wasm \
--payment-contract-path contracts/standard_payment.wasm \
--payment-amount 100000 \
--gas-price 10 \
--from-private-key-path ../hack/docker/keys/faucet-account/account-private.pem \
--from-public-key-path ../hack/docker/keys/faucet-account/account-public.pem \
--to-public-key-path ./server/test.public.key \
--amount 10000000
NOTE: If you are connecting to a HTTPS endpoint which uses a self-signed certificate, which is the case in local testing, you have to relax the SSL certificate checks in Node.js like so:
$ export NODE_TLS_REJECT_UNAUTHORIZED=0
$ node ./server/dist/transfer.js \
--host-url https://localhost:8443 \
...
If successful, it should print something like this:
Transfering tokens to account 045499d51a013e06c6cbb5734843cf3c7f08d66af312d81238ffeb54244f1800
Deploying 7401ecbe8b2c4e4de2c1e6422fddcfd1ae9d128058e2e6dba97ba62fc51db734 to http://localhost:8401
Done.
You can also confirm it in the node's logs in hack/docker
:
$ docker logs --tail 1 node-0
18:13:45.264 [grpc-default-executor-2] INFO i.c.casper.MultiParentCasperImpl - Received Deploy 7401ecbe8b2c4e4de2c1e6422fddcfd1ae9d128058e2e6dba97ba62fc51db734 (f78786150599b50a1353476f5e2f12cd13c214e512096741c48e7ec63639af56 / 1)
The auto-propose feature is by default not enabled in the hack/docker
setup, so you have to manually trigger proposal.
$ ./client.sh node-0 propose
Response: Success! Block d1d95074f4... created and added.
Following this we can check the status of our deploy. The result of the processing and the fault tolerance can be found in the output:
$ ./client.sh node-0 show-deploy 7401ecbe8b2c4e4de2c1e6422fddcfd1ae9d128058e2e6dba97ba62fc51db734
deploy {
deploy_hash: "7401ecbe8b2c4e4de2c1e6422fddcfd1ae9d128058e2e6dba97ba62fc51db734"
header {
account_public_key: "f78786150599b50a1353476f5e2f12cd13c214e512096741c48e7ec63639af56"
timestamp: 1562350425051
gas_price: 0
body_hash: "1ba3a8335e68cbfd461865876bccc9225c560db9045d862ad16d26e3bbbe0a87"
}
...
}
processing_results {
block_info {
summary {
block_hash: "d1d95074f4779c8de1ed851f22f3bb6c71089359b443b46f747606b1fbc0c974"
...
}
status {
fault_tolerance: -1.0
stats {
block_size_bytes: 957577
deploy_error_count: 0
}
}
}
cost: 20803
is_error: false
error_message: ""
}
If the deploy was successfully executed we can check the balance of the account we wished to give the tokens to:
$ ./client.sh node-0 query-state \
-t address \
-k 045499d51a013e06c6cbb5734843cf3c7f08d66af312d81238ffeb54244f1800 \
-p "/" \
-b d1d95074f4779c8de1ed851f22f3bb6c71089359b443b46f747606b1fbc0c974
account {
public_key: "045499d51a013e06c6cbb5734843cf3c7f08d66af312d81238ffeb54244f1800"
main_purse {
uref: "e698d314cd8004ca6cdfc5b5ea94b8c930aa3cd108bb32d6a5e9f53bcc201f75"
access_rights: READ_ADD_WRITE
}
known_urefs {
name: "URef(9251312d6c8a3d702a0b7e7754074dd920e5d2af1cf25e75fd2225ba845326ef, READ_ADD_WRITE)"
key {
uref {
uref: "9251312d6c8a3d702a0b7e7754074dd920e5d2af1cf25e75fd2225ba845326ef"
access_rights: READ_ADD_WRITE
}
}
}
known_urefs {
name: "URef(c1a7e37cadf6c5d11cec42a3ffb8a6c9d4a6b9e1da56a88c50b33ffd130ad043, READ_ADD_WRITE)"
key {
uref {
uref: "c1a7e37cadf6c5d11cec42a3ffb8a6c9d4a6b9e1da56a88c50b33ffd130ad043"
access_rights: READ_ADD_WRITE
}
}
}
known_urefs {
name: "mint"
key {
uref {
uref: "c40e2456dae1fa259a134fe1baba639066125b53515c888fe3086cc46e9e40b2"
access_rights: READ_ADD_WRITE
}
}
}
known_urefs {
name: "pos"
key {
uref {
uref: "5fcf27e682ed6856c575200740238f24247d178f3703539169631c11ba6fcc7c"
access_rights: READ_ADD_WRITE
}
}
}
associated_keys {
public_key: "045499d51a013e06c6cbb5734843cf3c7f08d66af312d81238ffeb54244f1800"
weight: 1
}
action_thresholds {
deployment_threshold: 1
key_management_threshold: 1
}
}
Based on the main_purse
we can issue a followup request to check the balance:
$ ./client.sh node-0 query-state \
-t uref \
-k e698d314cd8004ca6cdfc5b5ea94b8c930aa3cd108bb32d6a5e9f53bcc201f75 \
-p "/" \
-b d1d95074f4779c8de1ed851f22f3bb6c71089359b443b46f747606b1fbc0c974
unit {
}
Alas, that's not the balance. We'll have to figure out how to get there, apparently there's an indirection from the purse to a local address we can't easily see.
You can access the explorer at https://localhost:8443 to create accounts and ask the faucet for tokens.