Updated replica to elected commit dcbf401f27d9b48354e68389c6d8293c4233b055. This incorporates the following executed proposals:
- Module hash: db07e7e24f6f8ddf53c33a610713259a7c1eb71c270b819ebd311e2d223267f0
- dfinity#2753
Allows to overwrite Content-Type, Content-Encoding, and Cache-Control HTTP headers with custom values via .ic-assets.json5 config file. Example .ic-assets.json5 file:
[
{
"match": "web-gz.data.gz",
"headers": {
"Content-Type": "application/octet-stream",
"Content-Encoding": "gzip"
}
}
]This change will trigger the update process for frontend canister (new module hash: 2ff0513123f11c57716d889ca487083fac7d94a4c9434d5879f8d0342ad9d759).
SNS canister IDs were not being parsed reliably. Now the candid file is being specified explicitly, which resolves the issue in at least some cases.
The command line interface for nns commands has been updated to:
- Give better help when the subnet type is incorrect
- Not offer --network as a flag given that it is unused
- List nns subcommands
dfx canister install and dfx deploy now have a -y flag that will automatically confirm any y/n checks made during canister installation.
The function for calling sns can now call any bundled binary.
dfx nns commands are used to deploy and manage local NNS canisters, such as:
- Governance for integration with the Internet Computer voting system
- Ledger for financial integration testing
- Internet Identity for user registration and authenttication
The asset canister now by default aliases any request to <asset> to <asset>.html or <asset>/index.html.
This can be disabled by setting the field "enable_aliasing" to false in a rule for that asset in .ic-assets.json.
This change will trigger frontend canister upgrades upon redeploying any asset canister.
Removes misleading panics when running dfx stop.
This enables easy access to toy ICP using command line tools and this key:
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEICJxApEbuZznKFpV+VKACRK30i6+7u5Z13/DOl18cIC+oAcGBSuBBAAK
oUQDQgAEPas6Iag4TUx+Uop+3NhE6s3FlayFtbwdhRVjvOar0kPTfE/N8N6btRnd
74ly5xXEBNSXiENyxhEuzOZrIWMCNQ==
-----END EC PRIVATE KEY-----
For example, you can create an identity in dfx by putting this key in the file ident-1.pem and importing it:
dfx identity import ident-1 ident-1.pem
dfx --identity ident-1 ledger balance
This behavior applies to Motoko, Rust and Custom canisters. If you want to disable this behavior, you can config it in dfx.json:
"canisters" : {
"app" : {
"shrink" : false,
}
}
It's now possible to define custom wasm metadata sections and their visibility in dfx.json.
At present, dfx can only add wasm metadata sections to canisters that are in wasm format. It cannot add metadata sections to compressed canisters. Since the frontend canister is now compressed, this means that at present it is not possible to add custom metadata sections to the frontend canister.
dfx no longer adds candid:service metadata to canisters of type "custom" by default. If you want dfx to add your canister's candid definition to your custom canister, you can do so like this:
"my_canister_name": {
"type": "custom",
"candid": "main.did",
"wasm": "main.wasm",
"metadata": [
{
"name": "candid:service"
}
]
},
This changelog entry doesn't go into all of the details of the possible configuration. For that, please see concepts/canister-metadata and the docs in the JSON schema.
Hyphens are not valid in shell environment variables, but do occur in canister names such as smiley-dapp. This poses a problem for vars with names such as CANISTER_ID_${CANISTER_NAME}. With this change, hyphens are replaced with underscores in environment variables. The canister id of smiley-dapp will be available as CANISTER_ID_smiley_dapp. Other environment variables are unaffected.
This allows users to deploy a set of SNS canisters.
When using dfx canister install, you can now pass auto for the --mode flag, which will auto-select install or upgrade depending on need, the same way dfx deploy does. The default remains install to prevent mistakes.
dfx generate's generated bindings use network-specific canister IDs depending on the generated language, but there was previously no way to configure which network this was, so it defaulted to local. A --network flag has been added for this purpose.
There is a new command that verifies that an SNS initialization config is valid.
There is a new command that creates an sns config template.
The wasms dir path had a $ which is unwanted and now gone.
Previously the incorrect wasm canister was installed.
Previously the did files and wasms could be incompatible.
dfx start and dfx replica now ignore the --enable-canister-http parameter.
You can still disable the canister http feature through configuration:
- ~/.config/dfx/networks.json:
.local.canister_http.enabled=false - dfx.json (project-specific networks) :
.networks.local.canister_http.enabled=false
- note that dfx will report an error if a custom canister's
wasmfield is a URL and the canister also hasbuildsteps.
A developer is now able to install NNS canisters, including back end canisters such as ledger and governance, and front end canisters such as nns-dapp and internet-identity, on their local DFX server. Usage:
dfx start --clean --background
dfx nns install
This feature currently requires that the network 'local' is used and that it runs on port 8080.
The network's port can be controlled by using the field "provider" in the network's definition, e.g. by setting it to "127.0.0.1:8080".
It is now possible to set the http adapter's log level in dfx.json or in networks.json:
"http": {
"enabled": true,
"log_level": "info"
}
By default, a log level of "error" is used, in order to keep the output of a first-time dfx start minimal. Change it to "debug" for more verbose logging.
Adds an index.d.ts file to the generated declarations, allowing for better type safety in TypeScript projects.
dfx start produces a lot of log output that is at best irrelevant for most users.
Most output is no longer visible unless either --verbose is used with dfx or the relevant part's (e.g. http adapter, btc adapter, or replica) log level is changed in dfx.json or networks.json.
When creating a new identity with dfx identity new, whereas previously it would have generated an Ed25519 key, it now generates a secp256k1 key. This is to enable users to write down a BIP39-style seed phrase, to recover their key in case of emergency, which will be printed when the key is generated and can be used with a new --seed-phrase flag in dfx identity import. dfx identity import is however still capable of importing an Ed25519 key.
- Allow passing did files larger than 2KB.
- Better integration with Motoko Playground.
- SHA256 hashes of all assets are displayed when deploying the asset canister.
- A query method is added to the asset canister that returns the entire asset hash tree together with the certificate containing the certified variables of the asset canister.
See https://forum.dfinity.org/t/fixing-incorrect-compute-allocation-fee/14830
Until the rollout is complete, dfx canister update-settings --compute-allocation <N>
will fail with an error from the replica such as the following:
The Replica returned an error: code 1, message: "Canister requested a compute allocation of 1% which cannot be satisfied because the Subnet's remaining compute capacity is 0%"
Canisters that specify a remote id for the network that's getting built falsely had their build steps run, blocking some normal use patterns of dfx deploy.
Canisters with a remote id specified no longer get built.
The same applies to dfx generate.
The running replica port and url are generally useful information. Previously the code to get the URL was embedded in the network proxy code. This moves it out into a library for reuse.
Instead, the build process relies on ic-wasm to provide candid metadata for the canister, and
shrinking the canister size by stripping debug symbols and unused fuctions.
Additionally, after build step, the .wasm file is archived with gzip.
from (repository path) |
to (path in dfinity/sdk repository) |
summary |
|---|---|---|
dfinity/cdk-rs /src/ic-certified-assets |
/src/canisters/frontend/ic-certified-asset |
the core of the frontend canister |
dfinity/certified-assets / |
/src/canisters/frontend/ic-frontend-canister |
wraps ic-certified-assets to build the canister wasm |
dfinity/agent-rs /ic-asset |
/src/canisters/frontend/ic-asset |
library facilitating interactions with frontend canister (e.g. uploading or listing assets) |
dfinity/agent-rs /icx-asset |
/src/canisters/frontend/icx-asset |
CLI executable tool - wraps ic-asset |
Both .ic-assets.json and .ic-assets.json5 are valid filenames config filename, though both will get parsed
as if they were JSON5 format. Example content of the .ic-assets.json5 file:
// comment
[
{
"match": "*", // comment
/*
keys below not wrapped in quotes
*/ cache: { max_age: 999 }, // trailing comma
},
]- Learn more about JSON5: https://json5.org/
Previously existing NNS binaries were not updated regardless of the NO_CLOBBER setting.
install_canister_wasm used to fail if installing a canister not listed in dfx.json. This use case is now supported.
When running dfx start or dfx replica, the path to the dashboard page is now printed.
This is so dfx doesn't connect to a project-specific network instead of the local shared network.
In combination with the "system-wide dfx start" feature, there is a potential difference to be aware of with respect to existing projects.
Since previous versions of dfx populate dfx.json with a networks.local definition that specifies port 8000, the behavior for existing projects won't change.
However, if you've edited dfx.json and removed the networks.local definition, the behavior within the project will change: dfx will connect to the shared local network on port 4943 rather than to the project-specific network on port 8000. You would need to edit webpack.config.js to match. If you have scripts, you can run the new command dfx info webserver-port from the project directory to retrieve the port value.
By default, dfx now manages the replica process in a way that is independent of any given dfx project. We've called this feature "system-wide dfx", even though it's actually specific to your user (storing data files under $HOME), because we think it communicates the idea adequately.
The intended benefits:
- deploying dapps from separate projects alongside one another, similar to working with separate dapps on mainnet
- run
dfx startfrom any directory - run
dfx stopfrom any directory, rather than having to remember where you last randfx start
We're calling this the "shared local network." dfx start and dfx stop will manage this network when run outside any project directory, or when a project's dfx.json does not define the local network. The dfx.json template for new projects no longer defines any networks.
We recommend that you remove the local network definition from dfx.json and instead use the shared local network. As mentioned above, doing so will make dfx use port 4943 rather than port 8000.
See Local Server Configuration for details.
dfx now stores data and control files in one of three places, rather than directly under .dfx/:
.dfx/network/local(for projects in which dfx.json defines the local network)$HOME/.local/share/dfx/network/local(for the shared local network on Linux)$HOME/Library/Application Support/org.dfinity.dfx/network/local(for the shared local network on MacOS)
There is also a new configuration file: $HOME/.config/dfx/networks.json. Its schema is the same as the networks element in dfx.json. Any networks you define here will be available from any project, unless a project's dfx.json defines a network with the same name. See The Shared Local Network for the default definitions that dfx provides if this file does not exist or does not define a local network.
This displays the port that the icx-proxy process listens on, meaning the port to connect to with curl or from a web browser.
This displays the listening port of the replica.
This displays the revision of the replica bundled with dfx, which is the same revision referenced in replica election governance proposals.
This displays the path to your user's networks.json file where all networks are defined.
greet method was marked as an update call, but it performs no state updates. Changing it to query call will result in faster execution.
The dfx schema command can now display the schema for either dfx.json or for networks.json. By default, it still displays the schema for dfx.json.
dfx schema --for networksIf you have a pre-initialized agent in your JS code, you can now pass it to createActor's options. Conflicts with the agentOptions config - if you pass both the agent option will be used and you will receive a warning.
const plugActor = createActor(canisterId, {
agent: plugAgent
})Users can now specify node_compatibility: true in declarations. The flag introduces node.js enhancements, which include importing isomorphic-fetch and configuring the default actor with isomorphic-fetch and host.
// dfx.json
"declarations": {
"output": "src/declarations",
"node_compatibility": true
}DFX new template now uses dfx generate instead of rsync. Adds deprecation warning to index.js in .dfx/<network-name>/<canister-name> encouringing developers to migrate to the dfx generate command instead. If you have a package.json file that uses rsync from .dfx, consider switching to something like this:
"scripts": {
"build": "webpack",
"prebuild": "npm run generate",
"start": "webpack serve --mode development --env development",
"prestart": "npm run generate",
// It's faster to only generate canisters you depend on, omitting the frontend canister
"generate": "dfx generate hello_backend"
},Using dfx wallet --network ic redeem-faucet-coupon <my coupon> faucet users have a much easier time to redeem their codes.
If the active identity has no wallet configured, the faucet supplies a wallet to the user that this command will automatically configure.
If the active identity has a wallet configured already, the faucet will top up the existing wallet.
Alternative faucets can be used, assuming they follow the same interface. To direct dfx to a different faucet, use the --faucet <alternative faucet id> flag.
The expected interface looks like the following candid functions:
redeem: (text) -> (principal);
redeem_to_wallet: (text, principal) -> (nat);
The function redeem takes a coupon code and returns the principal to an already-installed wallet that is controlled by the identity that called the function.
The function redeem_to_wallet takes a coupon code and a wallet (or any other canister) principal, deposits the cycles into that canister and returns how many cycles were deposited.
By default, if dfx is not running on the ic (or networks with a different name but the same configuration), it will automatically create a cycles wallet in case it hasn't been created yet.
It is now possible to inhibit automatic wallet creation by setting the DFX_DISABLE_AUTO_WALLET environment variable.
When installing a new WASM module to a canister, DFX will now wait for the updated state (i.e. the new module hash) to be visible in the replica's certified state tree before proceeding with post-installation tasks or producing a success status.
dfx config has been removed. Please update Bash scripts to use jq, PowerShell scripts to use ConvertTo-Json, nushell scripts to use to json, etc.
Command flags have been moved to a more traditional location; they are no longer positioned per subcommand, but instead are able to be all positioned after the final subcommand. In prior versions, a command might look like:
dfx --identity alice canister --network ic --wallet "$WALLET" create --allThis command can now be written:
dfx canister create --all --network ic --wallet "$WALLET" --identity aliceThe old syntax is still available, though, so you don't need to migrate your scripts.
When using dfx canister update-settings, it is easy to mistake --controller for --add-controller. For this reason --controller has been renamed to --set-controller.
This is a breaking change. The only thing this was still serving was the /_/candid endpoint. If you need to retrieve the candid interface for a local canister, you can use dfx canister metadata <canister> candid:service.
- if there is no wallet to upgrade
- if trying to upgrade a local wallet from outside of a project directory
Canister creation fee was calculated with 1T cycles instead of 0.1T.
When dfx deploy and dfx canister install upgrade a canister, they ensure that the new candid interface is compatible with the previous candid interface. They write a file with extension .old.did that contains the previous interface. In some circumstances these files could be written in the project directory. dfx now always writes them under the .dfx/ directory.
This fixes the following error:
> dfx canister install --wasm ~/counter.wasm eop7r-riaaa-aaaak-qasxq-cai
Error: Failed while determining if canister 'eop7r-riaaa-aaaak-qasxq-cai' is remote on network 'ic'.
Caused by: Failed while determining if canister 'eop7r-riaaa-aaaak-qasxq-cai' is remote on network 'ic'.
Failed to figure out if canister 'eop7r-riaaa-aaaak-qasxq-cai' has a remote id on network 'ic'.
Invalid argument: Canister eop7r-riaaa-aaaak-qasxq-cai not found in dfx.jsonIt is now possible to specify the replica's log level. Possible values are critical, error, warning, info, debug, and trace.
The log level defaults to the level 'error'. Debug prints (e.g. Debug.print("...") in Motoko) still show up in the console.
The log level can be specified in the following places (See system-wide dfx start for more detailed explanations on the network types):
- In file
networks.jsonin the field<network name>.replica.log_levelfor shared networks. - In file
dfx.jsonin the fieldnetworks.<network name>.replica.log_levelfor project-specific networks. - In file
dfx.jsonin the fielddefaults.replica.log_levelfor project-specific networks. Requires a project-specific network to be run, otherwise this will have no effect.
Canister sandboxing is enabled to be consistent with the mainnet.
It is now possible to do e.g. dfx ledger account-id --of-canister fg7gi-vyaaa-aaaal-qadca-cai as well as dfx ledger account-id --of-canister my_canister_name when checking the ledger account id of a canister.
Previously, dfx only accepted canister aliases and produced an error message that was hard to understand.
Motivated by this forum post.
It is still possible to pin the dfx version by adding "dfx":"<dfx version to pin to>" to a project's dfx.json.
The prompt for entering your passphrase in order to decrypt an identity password read: "Please enter a passphrase for your identity" However, at that point, it isn't "a" passphrase. It's either your passphrase, or incorrect. Changed the text in this case to read: "Please enter the passphrase for your identity"
dfx ledger create-canister gets a new option --subnet-type that allows users to choose a type of subnet that their canister can be created on. Additionally, a dfx ledger show-subnet-types is introduced which allows to list the available subnet types.
Updated replica to release candidate 93dcf2a2026c34330c76149dd713d89e37daa533.
This also incorporates the following executed proposals:
- 85007
- 84391
- 83786
- 82425
- 81788
- 81571
- 80992
- 79816
- 78693
- 77589
- 76228
- 75700
- 75109
- 74395
- 73959
- 73714
- 73368
- 72764
Updated ic-ref to 0.0.1-1fba03ee
- introduce awaitKnown
- trivial implementation of idle_cycles_burned_per_day
- Module hash: b944b1e5533064d12e951621d5045d5291bcfd8cf9d60c28fef02c8fdb68e783
- https://github.com/dfinity/cycles-wallet/commit/fa86dd3a65b2509ca1e0c2bb9d7d4c5be95de378
- Module hash: 6c8f7a094060b096c35e4c4499551e7a8a29ee0f86c456e521c09480ebbaa8ab
- dfinity#2720
The feature is not yet implemented on icx-proxy-level, and is causing 500 HTTP response for some type of assets every second request.
fix: dfx now only adds candid:service metadata to custom canisters that have at least one build step
This way, if a canister uses a premade canister wasm, dfx will use it as-is.
It is now possible to develop multiple-canister projects using the Motoko VSCode extension.
Patches a JavaScript language binding compatibility issue encountered in web browsers which do not support the (?.) operator.
dfx is now capable of displaying the schema for dfx.json. You can see the schema by running dfx schema or write the schema to a file with dfx schema --outfile path/to/file/schema.json.
- The
.ic-assets.jsonfile should be placed inside directory with assets, or its subdirectories. Multiple config files can be used (nested in subdirectories). Example of.ic-assets.jsonfile format:
[
{
"match": ".*",
"cache": {
"max_age": 20
},
"headers": {
"X-Content-Type-Options": "nosniff"
},
"ignore": false
},
{
"match": "**/*",
"headers": null
},
{
"match": "file.json",
"ignore": true
}
]-
Configuring assets works only during asset creation - any changes to
.ic-assets.jsonfiles won't have any effect effect for assets that have already been created. We are working on follow up implementation with improvements to handle updating these properties. -
headersfrom multiple applicable rules are being stacked/concatenated, unlessnullis specified, which resets/empties the headers. -
Both
"headers": {}and absence ofheadersfield don't have any effect on end result. -
Valid JSON format is required, i.e. the array of maps,
matchfield is required. Only the following fields are accepted:cache,ignore,headers,match. The glob pattern has to be valid. -
The way matching rules work:
- The most deeply nested config file takes precedence over the one in parent dir. In other words, properties from a rule matching a file in a subdirectory override properties from a rule matching a file in a parent directory
- Order of rules within file matters - last rule in config file takes precedence over the first one
-
The way
ignorefield works:- By default, files that begin with a
.are ignored, while all other files are included. - The
.ignorefield overrides this, if present. - If a directory is ignored, file and directories within it cannot be un-ignored.
- A file can be ignored and un-ignored many times, as long as any of its parent directories haven't been ignored.
- By default, files that begin with a
A longstanding bug with dfx deploy is that if an installation is skipped (usually an implicitly included dependency), it still requires arguments even if the installed canister doesn't. As of this release that bug is now fixed.
Configures the replica to emit additional logging from the bitcoin canister whenever the bitcoin feature is enabled. This helps show useful information to developers, such as the bitcoin height that the replica currently sees.
Prior to 0.11.0, a custom canister's build field could be left off if dfx build was never invoked. To aid in deploying prebuilt canisters, this behavior is now formalized; omitting build is equivalent to build: [].
dfx build, in Rust canisters, now uses the --locked flag when building with Cargo. To offset this, dfx new --type rust now runs cargo update on the resulting project.
ECDSA signature signing is now enabled by default in new projects, or by running dfx start --clean.
A test key id "Secp256k1:dfx_test_key" is ready to be used by locally created canisters.
Updated replica to elected commit 6e86169e98904047833ba6133e5413d2758d90eb. This incorporates the following executed proposals:
The names of canisters created for new projects have changed.
After dfx new <project>, the canister names are:
<project>_backend(previously<project>)<project>_frontend(previously<project>_assets)
For example, to query a canister's candid service definition: dfx canister metadata hello_backend candid:service
The dfx internal webserver now only services the /_/candid endpoint. This
is now deprecated. If you were using this to query candid definitions, you
can instead use dfx canister metadata.
Optimize Rust canister WASM module via ic-wasm library instead of ic-cdk-optimizer. A separate installation of ic-cdk-optimizer is no longer needed.
The actual optimization was kept the same.
Enables passing large arguments that cannot be passed directly in the command line using the --argument-file flag. For example:
- Named file:
dfx canister call --argument-file ./my/argument/file.txt my_canister_name greet - Stdin:
echo '( null )' | dfx canister call --argument-file - my_canister_name greet
A lower threshold was no longer necessary.
The bitcoin adapter's logging can be very verbose if debug logging is enabled, making it difficult to make sense of what's going on. On the other hand, these logs are useful for triaging problems.
To get the best of both worlds, this release adds support for an additional configuration option in dfx.json:
"bitcoin": {
"enabled": true,
"nodes": ["127.0.0.1:18444"],
"log_level": "info" <------- users can now configure the log level
}
By default, a log level of "info" is used, which is relatively quiet. Users can change it to "debug" for more verbose logging.
This includes the following changes:
- Fetch did file from canister metadata
- Better flamegraph support
- Fix bigint error for vec nat8 type
After dfx start --host 127.0.0.1:0, the dfx webserver will listen on an ephemeral port. It stores the port value in .dfx/webserver-port. dfx will now look for this file, and if a port is contained within, use that port to connect to the dfx webserver.
Running dfx deploy, dfx canister id, dfx canister call and so forth work as expected
if run from within any subdirectory of a dfx project. Previously, this would create
canister_ids.json or .dfx/local/canister_ids.json within the subdirectory.
You can now add your own custom post-installation/post-deployment tasks to any canister type. The new post-install key for canister objects in dfx.json can be a command or list of commands, similar to the build key of custom canisters, and receives all the same environment variables. For example, to replicate the upload task performed with assets canisters, you might set "post-install": "icx-asset sync $CANISTER_ID dist".
Assets are now uploaded directly from their source directories, rather than first being copied to an output directory.
If you're using dfx deploy, you won't see any change in functionality. If you're running
dfx canister install --mode=upgrade, changed files in asset source directories will
be detected and uploaded even without an intervening dfx build.
The environment variable format CANISTER_CANDID_{name}, used in Rust projects, was deprecated in 0.9.2, to be unified with the variables CANISTER_CANDID_PATH_{name} which are used in other project types. It has now been removed. Note that you will need to update ic-cdk-macros if you use the #[import] macro.
The dfx config command has several issues and is ultimately a poor replacement for jq. The command is being deprecated, and will be removed in a later release; we recommend switching to jq or similar tools (e.g. ConvertTo-Json in PowerShell, to json in nushell, etc.)
Build scripts now always receive a CWD of the DFX project root, instead of wherever dfx was invoked from, and a bare script script.sh can be specified without needing to prefix with ./.
Motoko canisters already included this metadata.
Also added this metadata to the asset canister wasm, which will cause the next deploy to install this new version.
Some developers mistakenly think that the freezing threshold is measured in cycles, but it is actually measured in seconds. To stop them from accidentally freezing their canisters, setting a freezing threshold above 50M seconds (~1.5 years) now requires a confirmation.
Resolves an issue where webpack-cli was was breaking when users tried to run npm start in a fresh project. For affected users of 0.10.1, you can resolve this issue manually by running npm install webpack@latest webpack-cli@latest terser-webpack-plugin@latest.
Ledger 7424ea8 deprecates the existing notify function with a switch parameter between creating and topping up a canister, and introduces two
functions for doing the same. This should mostly be invisible to users, except that previously, if dfx ledger create-canister or dfx ledger top-up
failed, you would call dfx ledger notify after correcting the issue. In order to support the change, this command has been changed to two subcommands:
dfx ledger notify create-canister and dfx ledger notify top-up.
Previously, the ledger commands assumed all transfers were made from the default subaccount for the identity principal. This feature adds a --from-subaccount flag to dfx ledger transfer, dfx ledger create-canister, and dfx ledger top-up, to enable making transfers from a selected subaccount. A --subaccount flag is also added to dfx ledger balance for convenience. Subaccounts are expected as 64-character hex-strings (i.e. 32 bytes).
When a canister with type rust is built and cargo-audit is installed, dfx will now check for vulnerabilities in the dependencies. If a vulnerability is found, dfx will recommend that the user update to a version without known vulnerabilities.
Calls made to retrieve the help output for canister update-settings was missing the freezing-threshold parameter.
WARN and ERROR messages are now clearly labelled as such, and the labels are colored accordingly.
This is now included when running dfx canister update-settings -h.
There is no real reason for dfx schema to not work when a broken dfx.json is in the current folder - this is actually a very common scenario when dfx schema gets used.
The candid file specified in the field canisters.<canister name>.candid of dfx.json, or if that not exists canisters.<canister name>.remote.candid, is now used when running dfx canister call, even when dfx fails to determine the canister type.
After running dfx start --enable-bitcoin twice in a row (stopping dfx in between), the second
launched replica would fail to connect to the btc adapter. This is because ic-starter
does not write a new configuration file if one already exists, so the configuration file
used by the replica referred to one socket path, while dfx passed a different socket path
to the btc adapter.
Now dfx reuses the previously-used unix domain socket path, for both the btc adapter and for the canister http adapter.
Previously, dfx stop would send the TERM signal to the running dfx and its child processes,
and then exit immediately.
This avoids interference between a dfx process performing cleanup at shutdown and a dfx process that is starting.
dfx ping now uses the anonymous identity, and no longer requires dfx.json to be present.
When the bitcoin feature is enabled, dfx was launching the replica with the "bitcoin_testnet" feature. The correct feature to use is "bitcoin_regtest".
dfx replica writes the port of the running replica to one of these locations:
- .dfx/replica-configuration/replica-1.port
- .dfx/ic-ref.port
dfx bootstrap will now use this port value, so it's no longer necessary to edit dfx.json after running dfx replica.
In dfx.json, the bootstrap, bitcoin, canister_http, and replica settings can
now be specified on the local network, rather than in the defaults field.
If one of these four fields is set for the local network, the corresponding field
in defaults will be ignored.
Example:
{
"networks": {
"local": {
"bind": "127.0.0.1:8000",
"canister_http": {
"enabled": true
}
}
}
}Updated agent-rs to 0.18.0
Updated Motoko from 0.6.28 to 0.6.29.
Updated replica to elected commit 8993849de5fab76e796d67750facee55a0bf6649. This incorporates the following executed proposals:
Updated ic-ref to 0.0.1-173cbe84
- add ic0.performance_counter system interface
- add system API for ECDSA signing
- allow optional "error_code" field in responses
- support gzip-compressed canister modules
- enable canisters to send HTTP requests
Dfx already points to the asset canister's assets directory, and copying to disk could sometimes lead to an annoying "too many open files" error.
On Linux, dfx 0.10.0 failed any operation with an HSM with the following error:
Error: IO: Dynamic loading not supported
The fix was to once again dynamically-link the Linux build.
Dfx is now capable of providing explanations and remediation suggestions for entire categories of errors at a time.
Explanations and suggestions will slowly be added over time.
To see an example of an already existing suggestion, run dfx deploy --network ic while using an identity that has no wallet configured.
Most errors that happen within dfx are now reported in much more detail. No more plain File not found without explanation what even was attempted.
fix: identities with configured wallets are not broken anymore and removed only when using the --drop-wallets flag
When an identity has a configured wallet, dfx no longer breaks the identity without actually removing it. Instead, if the --drop-wallets flag is specified, it properly removes everything and logs what wallets were linked, and when the flag is not specified, it does not remove anything.
The behavior for identities without any configured wallets is unchanged.
dfx command-line parameters for bitcoin integration:
dfx start --enable-bitcoin # use default node 127.0.0.1:18444
dfx start --enable-bitcoin --bitcoin-node <node>The above examples also work for dfx replica.
These default to values from dfx.json:
.defaults.bitcoin.nodes
.defaults.bitcoin.enabled
The --bitcoin-node parameter, if specified on the command line, implies --enable-bitcoin.
If --enable-bitcoin or .defaults.bitcoin.enabled is set, then dfx start/replica will launch the ic-btc-adapter process and configure the replica to communicate with it.
Default behaviour changed for dfx wallet balance, it will now print cycles amount upscaled to trillions.
New flag --precise added to dfx wallet balance. Allows to get exact amount of cycles in wallet (without upscaling).
dfx command-line parameters for canister http requests integration:
dfx start --enable-canister-http
dfx replica --enable-canister-http
This defaults to the following value in dfx.json:
.defaults.canister_http.enabled
Specifying the network provider as https://ic0.app/ instead of https://ic0.app is now recognised as the real IC network.
Added ic-canister-http-adapter to the binary cache.
Updated Motoko from 0.6.26 to 0.6.28.
Updated replica to elected commit b90edb9897718730f65e92eb4ff6057b1b25f766. This incorporates the following executed proposals:
Updated icx-proxy to commit c312760a62b20931431ba45e5b0168ee79ea5cda
- Added gzip and deflate body decoding before certification validation.
- Fixed unzip and streaming bugs
- Added Prometheus metrics endpoint
- Added root and invalid ssl and dns mapping
Before this, deploying a canister with an opt Foo init argument without specifying an --argument would lead to an error:
$ dfx deploy
Error: Invalid data: Expected arguments but found none.With this change, this isn't an error anymore, but instead null is passed as a value. In general, if the user does not provide an --argument, and if the init method expects only opt arguments, then dfx will supply null for each argument.
Note in particular that this does not try to match opt arguments for heterogeneous (opt/non-opt) signatures. Note moreover that this only impacts a case that would previously error out, so no existing (working) workflows should be affected.
This check was previously performed on local networks, but not on mainnet.
Allows one to provide the .did file for calls to an arbitrary canister.
You no longer need a DFX project setup with a build task to install an already-built wasm module into a canister ID. The new --wasm <path> flag to dfx canister install will bypass project configuration and install the wasm module at <path>. A DFX project setup is still recommended for general use; this should mostly be used for installing pre-built canisters. Note that DFX will also not perform its usual checks for API/ABI/stable-memory compatibility in this mode.
Cycle counts can now exceed the previously set maximum of 2^64. The new limit is 2^128. A new wallet version has been bundled with this release that supports the new cycle count. You will not be able to use this feature with your existing wallets without running dfx wallet upgrade, but old wallets will still work just fine with old cycle counts.
dfx will once again display 'dfx is already running' if dfx is already running, rather than 'Address already in use'.
As a consequence, after dfx start failed to notice that dfx was already running,
it would replace .dfx/pid with an empty file. Later invocations of dfx stop
would display no output and return a successful exit code, but leave dfx running.
This makes the behavior match the usage text of the command:
<CANISTER> Specifies the canister name or id to update. You must specify either canister name/id or the --all option
When upgrading a canister, dfx deploy and dfx canister install skip installing the .wasm
if the wasm hash did not change. This avoids a round trip through stable memory for all
assets on every dfx deploy, for example. By passing this argument, dfx will instead
install the wasm even if its hash matches the already-installed wasm.
A new environment variable, DFX_CACHE_ROOT, has been introduced to allow setting the cache root directory to a different location than the configuration root directory. Previously DFX_CONFIG_ROOT was repurposed for this which only allowed one location to be set for both the cache and configuration root directories.
This is a breaking change since setting DFX_CONFIG_ROOT will no longer set the cache root directory to that location.
Previously, dfx canister call --with-cycles 1 would silently ignore the --with-cycles argument as the DFX principal has no way to pass cycles and the call must be forwarded through the wallet. Now it will error instead of silently ignoring it. To forward a call through the wallet, use --wallet $(dfx identity get-wallet), or --wallet $(dfx identity --network ic get-wallet) for mainnet.
The local replica sets its parameters according to the subnet type defined in defaults.replica.subnet_type, defaulting to 'application' when none is specified.
This makes it less likely to accidentally hit the 'cycles limit exceeded' error in production. Since the previous default was system, you may see these types errors in development instead.
Possible values for defaults.replica.subnet_type are: "application", "verifiedapplication", "system"
Example how to specify the subnet type:
{
"defaults": {
"replica": {
"subnet_type": "verifiedapplication"
}
}
}dfx ledger fabricate-cycles <canister (id)> <optional amount> can be used during local development to create cycles out of thin air and add them to a canister. Instead of supplying a canister name or id it is also possible to use --all to add the cycles to every canister in the current project. When no amount is supplied, the command uses 10T cycles as default. Using this command with --network ic will result in an error.
dfx identity new and dfx identity import now ask you for a password to encrypt the private key (PEM file) when it is stored on disk.
If you decide to use a password, your key will never be written to disk in plain text.
In case you don't want to enter your password all the time and want to take the risk of storing your private key in plain text, you can use the --disable-encryption flag.
The default identity as well as already existing identities will NOT be encrypted. If you want to encrypt an existing identity, use the following commands:
dfx identity export identity_name > identity.pem
# if you have set old_identity_name as the identity that is used by default, switch to a different one
dfx identity use other_identity
dfx identity remove identity_name
dfx identity import identity_name identity.pemIf you want to get your identity out of dfx, you can use dfx identity export identityname > exported_identity.pem. But be careful with storing this file as it is not protected with your password.
If you want to script identity creation and don't care about overwriting existing identities, you now can use the --force flag for the commands dfx identity new and dfx identity import.
When running dfx deploy --network ic, dfx canister --network ic create, or dfx identity --network ic get-wallet dfx no longer automatically creates a cycles wallet for the user if none is configured. Instead, it will simply report that no wallet was found for that user.
Dfx still creates the wallet automatically when running on a local network, so the typical workflow of dfx start --clean and dfx deploy will still work without having to manually create the wallet.
When something went wrong during identity creation, the identity was not listed as existing. But when trying to create an identity with that name, it was considered to be already existing.
Added command-line parameters:
dfx start --enable-bitcoin --btc-adapter-config <path>
dfx replica --enable-bitcoin --btc-adapter-config <path>These default to values from dfx.json:
.defaults.bitcoin.btc_adapter_config
.defaults.bitcoin.enabled
The --btc-adapter-config parameter, if specified on the command line, implies --enable-bitcoin.
If --enable-bitcoin or .defaults.bitcoin.enabled is set, and a btc adapter configuration is specified, then dfx start/replica will launch the ic-btc-adapter process.
This integration is not yet complete, pending upcoming functionality in ic-starter.
dfx now displays the context of an error in several places where previously the only error message would be something like "No such file or directory."
Webpack dev server now works for Node 18 (and should work for Node 17). A few packages are also upgraded
Updated to version 0.14.0 of agent-rs
- Module hash: bb001d1ebff044ba43c060956859f614963d05c77bd778468fce4de095fe8f92
- https://github.com/dfinity/cycles-wallet/commit/f18e9f5c2f96e9807b6f149c975e25638cc3356b
Updated replica to elected commit b3788091fbdb8bed7e527d2df4cc5e50312f476c. This incorporates the following executed proposals:
Added the ic-btc-adapter binary to the cache.
Updated Motoko from 0.6.25 to 0.6.26.
In preparation for BTC integration, added configuration for the bitcoind port:
{
"canisters": {},
"defaults": {
"bitcoind": {
"port": 18333
}
}
}Updated icx-proxy to commit 594b6c81cde6da4e08faee8aa8e5a2e6ae815602, now static-linked.
- upgrade HTTP calls upon canister request
- no longer proxies /_/raw to the dfx internal webserver
- allows for generic StreamingCallback tokens
Updated replica to blessed commit d004accc3904e24dddb13a11d93451523e1a8a5f. This incorporates the following executed proposals:
Updated Motoko from 0.6.21 to 0.6.25.
Newly deployed Motoko canisters now embed the Candid interface and Motoko stable signatures in the Wasm module.
dfx deploy and dfx canister install will automatically check
1) the backward compatible of Candid interface in both upgrade and reinstall mode;
2) the type safety of Motoko stable variable type in upgrade mode to avoid accidentally lossing data;
See Upgrade compatibility for more details.
The three canister types that use a custom build tool - assets, rust, and custom - now all support the same set of environment variables during the build task:
DFX_VERSION- The version of DFX that was used to build the canister.DFX_NETWORK- The network name being built for. Usuallyicorlocal.CANISTER_ID_{canister}- The canister principal ID of the canister{canister}registered indfx.json.CANISTER_CANDID_PATH_{canister}- The path to the Candid interface file for the canister{canister}among your canister's dependencies.CANISTER_CANDID_{canister}(deprecated) - the same asCANISTER_CANDID_PATH_{canister}. This is provided for backwards compatibility withrustandcustomcanisters, and will be removed in dfx 0.10.0.CANISTER_ID- Same asCANISTER_ID_{self}, where{self}is the name of this canister.CANISTER_CANDID_PATH- Same asCANISTER_CANDID_PATH_{self}, where{self}is the name of this canister.
If you have an installation of the ICP Ledger (see Ledger Installation Guide), dfx ledger balance and dfx ledger transfer now support
--ledger-canister-id parameter.
Some examples:
$ dfx ledger \
--network local \
balance \
--ledger-canister-id rrkah-fqaaa-aaaaa-aaaaq-cai
1000.00000000 ICP
$ dfx ledger \
--network local \
transfer --amount 0.1 --memo 0 \
--ledger-canister-id rrkah-fqaaa-aaaaa-aaaaq-cai 8af54f1fa09faeca18d294e0787346264f9f1d6189ed20ff14f029a160b787e8
Transfer sent at block height: 1The dfx ledger account-id can now compute addresses of principals and canisters.
The command also supports ledger subaccounts now.
dfx ledger account-id --of-principal 53zcu-tiaaa-aaaaa-qaaba-cai
dfx ledger --network small02 account-id --of-canister ledger_demo
dfx ledger account-id --of-principal 53zcu-tiaaa-aaaaa-qaaba-cai --subaccount 0000000000000000000000000000000000000000000000000000000000000001All dfx commands will now print the full stack of errors that led to the problem, not just the most recent error.
Example:
Error: Subaccount '00000000000000000000000000000000000000000000000000000000000000000' is not a valid hex string
Caused by:
Odd number of digits
quill generate currently outputs .pem files without an EC PARAMETERS section.
dfx identity import will now correctly identify these as EC keys, rather than Ed25519.
dfx now calls transfer rather than send_dfx, and sets the created_at_time field in order to retry the following commands:
- dfx ledger create-canister
- dfx ledger top-up
- dfx ledger transfer
It's now possible to specify that a canister in dfx.json references a "remote" canister on a specific network, that is, a canister that already exists on that network and is managed by some other project.
Motoko, Rust, and custom canisters may be configured in this way.
This is the general format of the configuration in dfx.json:
{
"canisters": {
"<canister name>": {
"remote": {
"candid": "<path to candid file to use when building on remote networks>",
"id": {
"<network name>": "<principal on network>"
}
}
}
}
}The "id" field, if set for a given network, specifies the canister ID for the canister on that network. The canister will not be created or installed on these remote networks. For other networks, the canister will be created and installed as usual.
The "candid" field, if set within the remote object, specifies the candid file to build against when building other canisters on a network for which the canister is remote. This definition can differ from the candid definitions for local builds.
For example, if have an installation of the ICP Ledger (see Ledger Installation Guide)
in your dfx.json, you could configure the canister ID of the Ledger canister on the ic network as below. In this case,
the private interfaces would be available for local builds, but only the public interfaces would be available
when building for --network ic.
{
"canisters": {
"ledger": {
"type": "custom",
"wasm": "ledger.wasm",
"candid": "ledger.private.did",
"remote": {
"candid": "ledger.public.did",
"id": {
"ic": "ryjl3-tyaaa-aaaaa-aaaba-cai"
}
}
},
"app": {
"type": "motoko",
"main": "src/app/main.mo",
"dependencies": [ "ledger" ]
}
}
}As a second example, suppose that you wanted to write a mock of the ledger in Motoko.
In this case, since the candid definition is provided for remote networks,
dfx build (with implicit --network local) will build app against the candid
definitions defined by mock.mo, but dfx build --network ic will build app against
ledger.public.did.
This way, you can define public update/query functions to aid in local testing, but
when building/deploying to mainnet, references to methods not found in ledger.public.did
will be reports as compilation errors.
{
"canisters": {
"ledger": {
"type": "motoko",
"main": "src/ledger/mock.mo",
"remote": {
"candid": "ledger.public.did",
"id": {
"ic": "ryjl3-tyaaa-aaaaa-aaaba-cai"
}
}
},
"app": {
"type": "motoko",
"main": "src/app/main.mo",
"dependencies": [ "ledger" ]
}
}
}It's now possible to generate the interface of a remote canister using a .did file using the dfx remote generate-binding <canister name>|--all command. This makes it easier to write mocks for local development.
Currently, dfx can generate .mo, .rs, .ts, and .js bindings.
This is how you specify how to generate the bindings in dfx.json:
{
"canisters": {
"<canister name>": {
"main": "<path to mo/rs/ts/js file that will be generated>",
"remote": {
"candid": "<path to candid file to use when generating bindings>"
"id": {}
}
}
}
}Upgraded from a432156f24faa16d387c9d36815f7ddc5d50e09f to ab8e3f5a04f0f061b8157c2889f8f5de05f952bb
- Support 128-bit system api for cycles
- Include canister_ranges in the state tree
- Removed limit on cycles in a canister
Updated replica to blessed commit 04fe8b0a1262f07c0cec1fdfa838a37607370a61. This incorporates the following executed proposals:
Updated Motoko from 0.6.20 to 0.6.21.
Breaking change: Canister commands, except for dfx canister create, will make the call directly, rather than via the user's wallet. The --no-wallet flag is thus removed from dfx canister as its behavior is the default.
When working with existing canisters, use the --wallet flag in conjunction with dfx identity get-wallet in order to restore the old behavior.
You will need to upgrade your wallet and each of your existing canisters to work with the new system. To do so, execute the following in each of your dfx projects:
dfx wallet upgrade
dfx canister --wallet "$(dfx identity get-wallet)" update-settings --all --add-controller "$(dfx identity get-principal)"To upgrade projects that you have deployed to the IC mainnet, execute the following:
dfx wallet --network ic upgrade
dfx canister --network ic --wallet "$(dfx identity --network ic get-wallet)" update-settings --all --add-controller "$(dfx identity get-principal)"dfx canister update-settings previously only let you overwrite the entire controller list; --add-controller and --remove-controller instead add or remove from the list.
dfx canister delete --no-withdrawal <canister> can be used to delete a canister without attempting to withdraw cycles.
This matches the value used in production and is meant to exceed the configured 5 MB wasmtime stack.
Fixed a defect in asset synchronization where no retries would be attempted after the first 30 seconds overall.
Updated Motoko from 0.6.11 to 0.6.20.
- Implement type union/intersection
- Transform for-loops on arrays into while-loops
- Tighten typing rules for type annotations in patterns
- Candid decoding: skip vec any fast
- Bump up MAX_HP_FOR_GC from 1GB to 3GB
- Candid decoder: Trap if a principal value is too large
- Eliminate bignum calls from for-iteration on arrays
- Improve scheduling
- Improve performance of bignum equality
- Stable signatures: frontend, metadata, command-line args
- Added heartbeat support
- Module hash: 53ec1b030f1891bf8fd3877773b15e66ca040da539412cc763ff4ebcaf4507c5
- https://github.com/dfinity/cycles-wallet/commit/57e53fcb679d1ea33cc713d2c0c24fc5848a9759
Updated replica to blessed commit 75138bbf11e201aac47266f07bee289dc18a082b. This incorporates the following executed proposals:
You can now declare "rust" canisters in dfx.json.
{
"canisters": {
"canister_name": {
"type": "rust",
"package": "crate_name",
"candid": "path/to/canister_name.did"
}
}
}Don't forget to place a Cargo.toml in your project root.
Then dfx will build the rust canister with your rust toolchain.
Please also make sure that you have added the WebAssembly compilation target.
rustup target add wasm32-unknown-unknownYou can also create new dfx project with a default rust canister.
dfx new --type=rust <project-name>Updates dependencies to latest for Webpack, and updates config. Additionally simplifies environment variables for canister ID's in config.
Additionally adds some polish to the starter template, including a favicon and using more semantic html in the example app
You can now override the location of any executable normally called from the cache by specifying
an environment variable. For example, DFX_ICX_PROXY_PATH will specify the path for icx-proxy.
dfx deploy can now reinstall a single canister, controlled by a new --mode=reinstall parameter.
This is destructive (it resets the state of the canister), so it requires a confirmation
and can only be performed on a single canister at a time.
dfx canister install --mode=reinstall <canister> also requires the same confirmation,
and no longer works with --all.
The included replica now supports canister_heartbeat. This only works with rust canisters for the time being,
and does not work with the emulator (dfx start --emulator).
This means dfx start --emulator has a chance of working if nix is not installed.
This has always been broken, even before dfx 0.7.0.
This means dfx start will work again on linux. This bug was introduced in dfx 0.8.2.
The --no-artificial-delay option not being the default has been causing a lot of confusion.
Now that we have measured in production and already applied a default of 600ms to most subnets deployed out there,
we have set the same default for dfx and removed the option.
Updated Motoko from 0.6.10 to 0.6.11.
- Assertion error messages are now reproducible (#2821)
By default dfx canister delete will return cycles to the default cycles wallet.
Cycles can be returned to a designated canister with --withdraw-cycles-to-canister and
cycles can be returned to dank at the current identity principal with --withdraw-cycles-to-dank
and to a designated principal with --withdraw-cycles-to-dank-principal.
It is now possible to create canisters with more than one controller by
passing multiple instances of the --controller parameter to dfx canister create`.
You will need to upgrade your wallet with dfx wallet upgrade, or dfx wallet --network ic upgrade
It is now possible to configure a canister to have more than one controller by
passing multiple instances of the --controller parameter to dfx canister update-settings`.
Breaking change: The controller parameter for dfx canister create is now passed as a named parameter,
rather than optionally following the canister name.
Old: dfx canister create [canister name] [controller] New: dfx canister create --controller [canister name]
Previously this would always look in $HOME/.dfinity/identity/creds.pem.
Updated the maximum value for the --memory-allocation value to be 12 GiB (12,884,901,888 bytes)
- Module hash: 9183a38dd2eb1a4295f360990f87e67aa006f225910ab14880748e091248e086
- https://github.com/dfinity/cycles-wallet/commit/9ef38bb7cd0fe17cda749bf8e9bbec5723da0e95
You will need to upgrade your wallet with dfx wallet upgrade, or dfx wallet --network ic upgrade
The included replica now supports public spec 0.18.0
- Canisters can now have more than one controller
- Adds support for 64-bit stable memory
- The replica now goes through an initialization sequence, reported in its status
as
replica_health_status. Until this reports ashealthy, queries or updates will fail. **dfx start --backgroundwaits to exit untilreplica_health_statusishealthy. ** If you rundfx startwithout--background, you can calldfx ping --wait-healthyto wait until the replica is healthy.
Updated Motoko from 0.6.7 to 0.6.10
- add Debug.trap : Text -> None (motoko-base #288)
- Introduce primitives for
Int⇔Floatconversions (#2733) - Fix crashing bug for formatting huge floats (#2737)
dfx generateThis new command will generate type declarations for canisters in dfx.json.
You can control what will be generated and how with corresponding configuration in dfx.json.
Under dfx.json → "canisters" → "<canister_name>", developers can add a "declarations" config. Options are:
-
"output" → directory to place declarations for that canister | default is "src/declarations/<canister_name>"
-
"bindings" → [] list of options, ("js", "ts", "did", "mo") | default is "js", "ts", "did"
-
"env_override" → a string that will replace process.env.{canister_name_uppercase}_CANISTER_ID in the "src/dfx/assets/language_bindings/canister.js" template.
js declarations output
-
index.js (generated from "src/dfx/assets/language_bindings/canister.js" template)
-
<canister_name>.did.js - candid js binding output
ts declarations output
- <canister_name>.did.d.ts - candid ts binding output
did declarations output
- <canister_name>.did - candid did binding output
mo declarations output
- <canister_name>.mo - candid mo binding output
Use it with either of these forms:
dfx identity use anonymous
dfx --identity anonymous ...Default identities are the pem files generated by dfx identity new ... which contain Ed25519 private keys.
They are located at ~/.config/dfx/identity/xxx/identity.pem.
Now, you can copy such pem file to another computer and import it there.
dfx identity new alice
cp ~/.config/dfx/identity/xxx/identity.pem alice.pem
# copy the pem file to another computer, then
dfx identity import alice alice.pemBefore, people can manually copy the pem files to the target directory to "import". Such workaround still works.
We suggest to use the import subcommand since it also validate the private key.
Define DFX_WALLET_WASM in the environment to use a different wasm module when creating or upgrading the wallet.
When the caller provides SHA-256 hashes (which dfx does), the asset canister will no longer recompute these hashes when committing the changes. These recomputations were causing canisters to run out of cycles, or to attempt to exceed the maximum cycle limit per update.
The 0.8.0 release includes updates and fixes that are primarily internal to improve existing features and functions rather than user-visible.
This was intended to skip verification of the wallet canister on the IC network, but ended up only writing to the wallets.json file if --force was passed.
-
Support for the latest version of the {IC} specification and replica.
-
Updating to latest versions of Motoko, Candid, and agent-rs
-
Changes to
dfx newproject template and JavaScript codegen to support type inference in IDE's -
Adding webpack dev server to project template
-
Migration path documented at https://sdk.dfinity.org/docs/release-notes/0.8.0-rn.html
Breaking changes to frontend code generation, documented in 0.8.0
dfx deploy and dfx canister install now compare the hash of the already-installed module with the hash of the built canister's wasm output. If they are the same, they leave the canister in place rather than upgrade it. They will still synchronize assets to an asset canister regardless of the result of this comparison.
The streaming callback mechanism now requires the following record structure for the token:
type StreamingCallbackToken = record {
key: text;
content_encoding: text;
index: nat;
sha256: opt blob;
};
Previously, the token could be a record with any set of fields.
Change the default cycle balance of a canister from 10T cycles to 3T cycles.
- Module hash: 1404b28b1c66491689b59e184a9de3c2be0dbdd75d952f29113b516742b7f898
- https://github.com/dfinity/cycles-wallet/commit/e902708853ab621e52cb68342866d36e437a694b
Fixed an issue where the controller can remove itself from the list of controllers even if it's the only one, leaving the wallet uncontrolled. Added defensive checks to the wallet's remove_controller and deauthorize methods.
When using dfx canister sign to generate a update message, a corresponding
request_status message is also signed and append to the json as signed_request_status.
Then after sending the update message, the user can check the request_status using
dfx canister send message.json --status.
Previously, dfx canister call would proxy queries and update calls via the wallet canister by default.
(There was the --no-wallet flag to bypass the proxy and perform the calls as the selected identity.)
However, this behavior had drawbacks, namely each dfx canister call was an inter-canister call
by default and calls would take a while to resolve. This fix makes it so that dfx canister call no longer
proxies via the wallet by default. To proxy calls via the wallet, you can do
dfx canister --wallet=<wallet-id> call.
This change adds the --no-artificial-delay flag to dfx start and dfx replica.
The replica shipped with dfx has always had an artificial consensus delay (introduced to simulate
a delay users might see in a networked environment.) With this new flag, that delay can
be lessened. However, you might see increased CPU utilization by the replica process.
This change introduces the deposit_cycles and uninstall_code management canister
methods as dedicated dfx canister subcommands.
This change updates the dfx commands so that they will accept either a canister name (sourced from your local project) or a valid canister id.
This change allows you to specify the format the return result for dfx canister request-status.
This change fixes a bug where deleting a canister on a network removed all other entries for the canister in the canister_ids.json file.
--network ic now points to the mainnet IC (as Sodium has been deprecated.)
The dedicated candid UI canister is installed on a local network when doing a dfx canister install
or dfx deploy.
This fixes an error which occurred when starting a replica right after stopping it.
dfx now supports a dedicated dfx ledger subcommand. This allows you to interact with the ledger
canister installed on the Internet Computer. Example commands include dfx ledger account-id which
prints the Account Identifier associated with your selected identity, dfx ledger transfer which
allows you to transfer ICP from your ledger account to another, and dfx ledger create-canister which
allows you to create a canister from ICP.
This is a breaking change to support 0.17.0 of the Interface Spec. Compute & memory allocation values
are set when creating a canister. An optional controller can also be specified when creating a canister.
Furthermore, dfx canister set-controller is removed, in favor of dfx canister update-settings which
allows the controller to update the controller, the compute allocation, and the memory allocation of the
canister. The freezing threshold value isn't exposed via dfx cli yet, but it may still be modified by
calling the management canister via dfx canister call aaaaa-aa update-settings
dfx now supports a dedicated dfx wallet subcommand. This allows you to interact with the cycles wallet
associated with your selected identity. For example, dfx wallet balance to get the cycle balance,
dfx wallet list-addresses to display the associated controllers & custodians, and dfx wallet send <destination> <amount>
to send cycles to another wallet.
- Module Hash: a609400f2576d1d6df72ce868b359fd08e1d68e58454ef17db2361d2f1c242a1
- https://github.com/dfinity/cycles-wallet/commit/06bb256ca0738640be51cf84caaced7ea02ca29d
- Module Hash: 3d5b221387875574a9fd75b3165403cf1b301650a602310e9e4229d2f6766dcc
- https://github.com/dfinity/cycles-wallet/commit/c3cbfc501564da89e669a2d9de810d32240baf5f
feat: The wallet_create_canister method now takes a single record argument, which includes canister settings.
DFX will now also delete assets from the container that do not exist in the project. This means if you stored assets in the container, and they are not in the project, dfx deploy or dfx install will delete them.
- now takes arguments as a single record parameter
- must now specify content type and content encoding, and may specify the sha256
Added dfx canister info command to get certified canister information. Currently this information is limited to the controller of the canister and the SHA256 hash of its WASM module. If there is no WASM module installed, the hash will be None.
- now takes a parameter, which is an empty record
- now returns an array of records
- use list() instead
feat: add --no-wallet flag and --wallet option to allow Users to bypass Wallet or specify a Wallet to use for calls (#1476)
Added --no-wallet flag to dfx canister and dfx deploy. This allows users to call canister management functionality with their Identity as the Sender (bypassing their Wallet canister.)
Added --wallet option to dfx canister and dfx deploy. This allows users to specify a wallet canister id to use as the Sender for calls.
--wallet and --no-wallet conflict with each other. Omitting both will invoke the selected Identity's wallet canister to perform calls.
Users can use dfx canister sign ... to generated a signed canister call in a json file. Then dfx canister send [message.json] to the network.
Users can sign the message on an air-gapped computer which is secure to host private keys.
-
signandsendcurrently don't proxy through wallet canister. Users should use the subcommands withdfx canister --no-wallet sign .... -
The
signoption--expire-afterwill set theingress_expiryto a future timestamp which is current plus the duration. Then users can send the message during a 5 minutes time window ending in thatingress_expirytimestamp. Sending the message earlier or later than the time window will both result in a replica error.
And add support for http requests in the base storage canister (with a default to /index.html).
This does not support other encodings than identity for now (and doesn't even return any headers). This support will be added to the upgraded asset storage canister built in #1482.
Added a test that uses curl localhost to test that the asset storage AND the webserver properly support the http requests.
This commit also upgrades tokio and reqwest in order to work correctly. There are also some performance issues noted (this is slower than the icx-http-server for some reason), but those are not considered criticals and could be improved later on.
Renamed the project_name in our own generated assets to canister_name, for things that are generated during canister build (and not project generation).
You can now a generate private key via OpenSSL or a simlar tool, import it into dfx, and use it to sign an ingress message.
openssl ecparam -name secp256k1 -genkey -out identity.pem
dfx identity import <name> identity.pem
dfx identity use <name>
dfx canister call ...- Please note that neither the JS agent nor the HTTP server have been updated yet to server such large assets.
- The existing interface is left in place for backwards-compatibility, but deprecated: ** retrieve(): use get() and get_chunk() instead ** store(): use create_batch(), create_chunk(), and commit_batch() instead ** list(): use keys() instead
- feat: dfx now provides CANISTER_ID_<canister_name> environment variables for all canisters to "npm build" when building the frontend.
- feat: AgentError due to request::Error will now include the reqwest error message in addition to "Could not reach the server"
- feat: Add secp256k1 support (dfx support to follow)
- feat: add option to specify initial cycles for newly created canisters (#1433)
Added option to dfx canister create and dfx deploy commands: --with-cycles <with-cycles>.
This allows the user to specify the initial cycle balance of a canister created by their wallet.
This option is a no-op for the Sodium network.
dfx canister create --with-cycles 8000000000 some_canister
dfx deploy --with-cycles 8000000000Help string:
Specifies the initial cycle balance to deposit into the newly
created canister. The specified amount needs to take the
canister create fee into account. This amount is deducted
from the wallet's cycle balance
- feat: install
dfxby version or tag (#1426)
This feature adds a new dfx command toolchain which have intuitive subcommands.
The toolchain specifiers can be a complete version number, major minor version, or a tag name.
dfx toolchain install 0.6.24 # complete version
dfx toolchain install 0.6 # major minor
dfx toolchain install latest # tag name
dfx toolchain default latest
dfx toolchain list
dfx toolchain uninstall latest- fix: onboarding related fixups (#1420)
Now that the Mercury Alpha application subnetwork is up and we are getting ready to onboard devs, the dfx error message for wallet creation has changed: For example,
dfx canister --network=alpha create hello
Creating canister "hello"...
Creating the canister using the wallet canister...
Creating a wallet canister on the alpha network.
Unable to create a wallet canister on alpha:
The Replica returned an error: code 3, message: "Sender not authorized to use method."
Wallet canisters on alpha may only be created by an administrator.
Please submit your Principal ("dfx identity get-principal") in the intake form to have one created for you.- feat: add deploy wallet subcommand to identity (#1414)
This feature adds the deploy-wallet subcommand to the dfx identity. The User provides the ID of the canister onto which the wallet WASM is deployed.
dfx identity deploy-wallet --help
dfx-identity-deploy-wallet
Installs the wallet WASM to the provided canister id
USAGE:
dfx identity deploy-wallet <canister-id>
ARGS:
<canister-id> The ID of the canister where the wallet WASM will be deployed
FLAGS:
-h, --help Prints help information
-V, --version Prints version information-
feat: dfx call random value when argument is not provided (#1376)
-
fix: canister call can take canister ids for local canisters even if … (#1368)
-
fix: address panic in dfx replica command (#1338)
-
fix: dfx new webpack.config.js does not encourage running 'js' through ts-… (#1341)
-
There have been updates, improvements, and new sample apps added to the examples repository.
All of Motoko sample apps in the examples repository have been updated to work with the latest release of the SDK.
There are new sample apps to illustrate using arrays (Quicksort) and building create/read/update/delete (CRUD) operations for a web application Superheroes.
-
The LinkedUp sample application has been updated to work with the latest release of Motoko and the SDK.