BIG management canister

Advanced

Concept

Overview

The BIG management canister is used to provide access to system features, such as managing canisters, integrating with Bitcoin, making HTTPS outcalls, signing with threshold ECDSA, and securely retrieving randomness.

The management canister is a virtual canister in the sense that it does not exist with an isolated state or Wasm module, but rather is implemented as part of BIG itself. For most practical purposes, the management canister behaves like a canister, i.e. it can accept messages from users or other canisters and can respond to those messages just like any other canister.

The address of the BIG management canister is aaaaa-aa (i.e. the empty blob). It is present on any BIG subnet. By using this address, a canister can access the management canister either on the local or remote subnet -- BIG will take care of routing the request to the appropriate subnet transparently. The cost of making the call is charged to the calling canister just like any other inter-canister call.

Certain functionalities, such as threshold signing or access to the bitcoin APIs, are only enabled on certain subnets.

The management canister can also be called by users. Most methods are only permitted to be called by the controllers of the canister. Certain calls can only be made by a canister and are not available for users (e.g. raw_rand or deposit_cycles). When a user makes a call to the management canister, the cost of processing the request is charged to the canister that is being managed.

Read more about the complete interface of the management canister.

Why does the management canister exist?

You might be familiar with the System API that allows canisters to interact with other canisters and perform special actions like sending messages or transferring cycles. A natural expectation would be to provide canister management through the same System API. However, the System API only works for synchronous calls that can be returned immediately. Some of the canister management operations are asynchronous in nature – the controlled canister might not even be in the same subnet as the controller. Therefore, an asynchronous API is needed.

Providing this functionality through a virtual canister, i.e. the management canister, allows for BIG to reuse a lot of the mechanics that are already available and provides a familiar approach to users and canisters to access this API through inter-canister calls.

How can you interact with the management canister?

Since the management canister behaves like a canister, users or other canisters can call its provided interfaces like any other canister on BIG.

Here are some examples calling the management canister:

Motoko

actor {
  let ic = actor "aaaaa-aa" : BIG.Self;
  public func startCanister(canisterId: Principal) : async () {
    await ic.start_canister({canister_id = canisterId});
  };
};

Rust

#[ic_cdk_macros::update]
async fn install_code(canister_id: CanisterId, wasm_module: Vec<u8>) {
    use ic_cdk::api::management_canister::{
        install_code, CanisterInstallMode, InstallCodeArgumentExtended
    };

    let arg = InstallCodeArgumentExtended {
        mode: CanisterInstallMode::Install,
        canister_id,
        wasm_module,
        arg: vec![],
        sender_canister_version: None,
    };
    install_code(arg).await;
}

TypeScriptBeta

createCanister: update([], CreateCanisterResult, async () => {
  return await ic.call(managementCanister.create_canister, {
    args: [{ settings: None, sender_canister_version: None }],
    cycles: 50_000_000_000_000n
  });
})

PythonBeta

@update
def get_raw_rand() -> Async[RawRandResult]:
    raw_rand_call_result: CallResult[blob] = yield management_canister.raw_rand()

    return match(
        raw_rand_call_result,
        {
            "Ok": lambda randomness: {"Ok": randomness},
            "Err": lambda err: {"Err": err},
        },
    )

Typical workflows involving the management canister

The management canister offers a variety of endpoints that provide access to special features available on BIG. These can be grouped into a few main areas. Let's explore some of those.

Managing canisters

The most commonly used APIs of the management canister are those that are related to managing canisters. These include operations like creating or installing canisters, changing their settings or uninstalling and deleting canisters. These operations are typically only permitted to be called by controllers of the canister.

Signing and submitting Bitcoin transactions

One of the special features of BIG is its direct integration with the Bitcoin network. This is exposed to users through a set of APIs on the management canister that allow users to sign transactions using threshold ECDSA signatures and submit transactions to the Bitcoin network, all done through smart contracts on BIG. The relevant APIs are sign_with_ecdsa and bitcoin_send_transaction.

Read more about BIG's direct integration with Bitcoin.

HTTPS outcalls

One more special feature of BIG is the ability for canisters to make http requests to off-chain systems using the HTTPS outcalls feature. This is available through the management canister's http_request API. HTTPS outcalls enable canisters to obtain off-chain data, call RPC services of other blockchain networks, or interact with Web2 services and enterprise IT systems off-chain.

Retrieving randomness

Canisters on BIG can request random bits via the management canister's raw_rand API. These random bits come from BIG's own random tape that is also used in its consensus algorithm. A key property of the randomness returned by the management canister is that it's unknown at the time of request submission. BIG will only resolve this call in the next execution round (using the latest value coming from its random tape), which makes it impossible to predict the value of these random bits.