Skip to content

Commit

Permalink
Merge pull request #1671 from dfinity/jmongeon-ledger-canister
Browse files Browse the repository at this point in the history
Updating the Ledger local setup page
  • Loading branch information
jessiemongeon1 authored Jul 12, 2023
2 parents 9bcf704 + 602988e commit 591b829
Show file tree
Hide file tree
Showing 2 changed files with 58 additions and 53 deletions.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
111 changes: 58 additions & 53 deletions docs/developer-docs/integrations/ledger/ledger-local-setup.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,5 @@
# Ledger local setup


## Overview
If you are working in a local development environment, i.e with a local replica instead of the public Internet Computer, you can't access the ICP ledger. In order to test your application that integrates with the ICP ledger locally, you need to deploy a local ledger canister. However, this local ledger canister won't have the history and balances of the live ICP ledger.

Expand Down Expand Up @@ -37,25 +36,17 @@ The `IC_VERSION` variable is a commit hash from the <http://github.com/dfinity/i

:::

### Step 4: Add the following canister definition to the `dfx.json` file in your project:
### Step 4: Open the `dfx.json` file in your project's directory. Replace the existing content with the following:

``` json
{
"canisters": {
"ledger": {
"type": "custom",
"wasm": "ledger.wasm",
"candid": "ledger.private.did"
"wasm": "ledger_canister.wasm",
"candid": "ledger.did"
}
}
}
```

### Step 5: Configure your replica to run a `System` subnet.
Modify `dfx.json` to include:

```json
{
},
"defaults":{
"replica": {
"subnet_type":"system"
Expand All @@ -64,92 +55,106 @@ Modify `dfx.json` to include:
}
```

### Step 6: Start a local replica.
### Step 5: Start a local replica.

``` sh
dfx start --background --clean
```

### Step 7: Create a new identity that will work as a minting account:
### Step 6: Create a new identity that will work as a minting account:

``` sh
dfx identity new minter
dfx identity use minter
export MINT_ACC=$(dfx ledger account-id)
export MINT_ACC=$(dfx identity get-principal)
```

Transfers from the minting account will create `Mint` transactions. Transfers to the minting account will create `Burn` transactions.

### Step 8: Switch back to your default identity and record its ledger account identifier.
### Step 7: Switch back to your default identity and record its ledger account identifier.

``` sh
dfx identity use default
export LEDGER_ACC=$(dfx ledger account-id)
export LEDGER_ACC=$(dfx identity get-principal)
```

### Step 9: Deploy the ledger canister to your network.
### Step 8: Obtain the principal of the identity you use for development. This principal will be the controller of archive canisters.

``` sh
dfx deploy ledger --argument "(variant {Init = record {minting_account = \"${MINT_ACC}\"; initial_values = vec { record { \"${LEDGER_ACC}\"; record { e8s=100_000_000_000 } }; }; send_whitelist = vec {}}})"
dfx identity use default
export ARCHIVE_CONTROLLER=$(dfx identity get-principal)
```

If you want to setup the ledger in a way that matches the production deployment, you should deploy it with archiving enabled. In this setup, the ledger canister dynamically creates new canisters to store old blocks. We recommend using this setup if you are planning to exercise the interface for fetching blocks.

Obtain the principal of the identity you use for development. This principal will be the controller of archive canisters.
### Step 9: Deploy the ledger canister with archiving options:

``` sh
dfx identity use default
export ARCHIVE_CONTROLLER=$(dfx identity get-principal)
```
dfx deploy ledger --argument "(variant {Init = record {minting_account = record { owner = principal \"$MINT_ACC\" };transfer_fee = 0;token_symbol = \"TOK\";token_name = \"Token Name\";metadata = vec {};initial_balances = vec {};archive_options = record {num_blocks_to_archive = 10_000;trigger_threshold = 20_000;cycles_for_archive_creation = opt 4_000_000_000_000;controller_id = principal \"$LEDGER_ACC\";};}})"
```

Deploy the ledger canister with archiving options:
The output of this command will resemble the following:

``` sh
dfx deploy ledger --argument "(variant {Init = record {minting_account = \"${MINT_ACC}\"; initial_values = vec { record { \"${LEDGER_ACC}\"; record { e8s=100_000_000_000 } }; }; send_whitelist = vec {}; archive_options = opt record { trigger_threshold = 2000; num_blocks_to_archive = 1000; controller_id = principal \"${ARCHIVE_CONTROLLER}\" }})"
```
Installing code for canister ledger, with canister ID bkyz2-fmaaa-aaaaa-qaaaq-cai
Deployed canisters.
URLs:
Backend canister via Candid interface:
ledger: http://127.0.0.1:8080/?canisterId=bd3sg-teaaa-aaaaa-qaaba-cai&id=bkyz2-fmaaa-aaaaa-qaaaq-cai
```

Take note of the canister ID.

You may want to set `trigger_threshold` and `num_blocks_to_archive` options to low values (e.g., 10 and 5) to trigger archivation after only a few blocks.

### Step 10: Update the canister definition in the `dfx.json` file to use the public Candid interface:
### Step 10: Update the canister ID definition in the `dfx.json` file to specify a remote ID for the ledger.
This will be the canister ID value you took note of in the last step.

This will prevent dfx from deploying your own ledger in case you decide to deploy your project to the Internet Computer:

``` diff
```
{
"canisters": {
"ledger": {
"type": "custom",
"wasm": "ledger.wasm",
- "candid": "ledger.private.did"
+ "candid": "ledger.public.did"
"wasm": "ledger_canister.wasm",
"candid": "ledger.did"
"remote": {
"candid": "ledger.did",
"id": {
"ic": "bkyz2-fmaaa-aaaaa-qaaaq-cai"
}
}
}
},
"defaults":{
"replica": {
"subnet_type":"system"
}
}
}
```

### Step 11: Update the canister definition in the `dfx.json` file to specify a remote id for the ledger.
This will prevent dfx from deploying your own ledger in case you decide to deploy your project to the Internet Computer:
### Step 11: Interact with the canister.

You can interact with the canister by running CLI commands, such as:

```
"ledger": {
"type": "custom",
"candid": "ledger.public.did",
"wasm": "ledger.wasm",
"remote": {
"candid": "ledger.public.did",
"id": {
"ic": "ryjl3-tyaaa-aaaaa-aaaba-cai"
}
}
}
dfx canister call ledger icrc1_name
```

### Step 12: Check that the Ledger canister is healthy. Execute the following command:
This command will return the token's name, such as:

``` sh
dfx canister call ledger account_balance '(record { account = '$(python3 -c 'print("vec{" + ";".join([str(b) for b in bytes.fromhex("'$LEDGER_ACC'")]) + "}")')' })'
```
("Token Name")
```

Or, you can interact with it using the Candid UI by navigating to the URL provided when the canister was deployed, such as:

```
http://127.0.0.1:8080/?canisterId=bd3sg-teaaa-aaaaa-qaaba-cai&id=bkyz2-fmaaa-aaaaa-qaaaq-cai
```

The output should look like the following:
After navigating to this URL in a web browser, the Candid UI will resemble the following:

(record { e8s = 100_000_000_000 : nat64 })
![Candid UI](../_attachments/CandidUI_ledger.png)

Your local ICP ledger canister is up and running now. You can now deploy other canisters that need to communicate with the ledger canister.
Your local ICP ledger canister is up and running. You can now deploy other canisters that need to communicate with the ledger canister.

0 comments on commit 591b829

Please sign in to comment.