Skip to content

Commit aac0602

Browse files
Merge pull request #1003 from dfinity/update-onchain
Update on-chain -> onchain
2 parents 985ec22 + 311ffc5 commit aac0602

File tree

8 files changed

+112
-25
lines changed

8 files changed

+112
-25
lines changed

archive/motoko/defi/README.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ The sample exchange is implemented in [Motoko](https://github.com/dfinity/exampl
1414

1515
## Architecture
1616

17-
The design of the IC allows for more complex on-chain computation. In combination with cheap storage, it is possible to have on-chain order books. This sample code takes advantage of these features and stores user balances and orders inside the exchange canister. The sample exchange functionality can be condensed into the following steps:
17+
The design of the IC allows for more complex onchain computation. In combination with cheap storage, it is possible to have onchain order books. This sample code takes advantage of these features and stores user balances and orders inside the exchange canister. The sample exchange functionality can be condensed into the following steps:
1818

1919
- Exchange takes custody of funds (different mechanism for tokens and ICP, see below).
2020

@@ -78,7 +78,7 @@ There are a number of token standards in development (e.g. IS20, DFT, and DRC20)
7878

7979
### Placing orders
8080

81-
After depositing funds to the exchange, the user can place orders. An order consists of two tuples. `from: (Token1, amount1)` and `to: (Token2, amount2)`. These orders get added to the exchange. What happens to these orders is specific to the exchange implementation. This sample provides a simple exchange that only executes exactly matching orders. Be aware this is just a toy exchange, and the exchange functionality is just for completeness.
81+
After depositing funds to the exchange, the user can place orders. An order consists of two tuples. `from: (Token1, amount1)` and `to: (Token2, amount2)`. These orders get added to the exchange. What happens to these orders is specific to the exchange implementation. This sample provides a simple exchange that only executes exactly matching orders. Be aware this is just a toy exchange, and the exchange functionality is just for completeness.
8282

8383
### Withdrawing funds
8484

@@ -112,7 +112,7 @@ or you can regenerate the URL `http://127.0.0.1:4943?canisterId=$(dfx canister i
112112

113113
### Step 2: To interact with the exchange, you can create a local Internet Identity by clicking the login button.
114114

115-
This sample project uses a local test version of Internet Identity. Do not use your mainnet Internet Identity, and this testnet Internet Identity will not work on the mainnet.
115+
This sample project uses a local test version of Internet Identity. Do not use your mainnet Internet Identity, and this testnet Internet Identity will not work on the mainnet.
116116

117117
### Step 3: When prompted, select **Create Internet Identity**.
118118

@@ -130,7 +130,7 @@ This sample project uses a local test version of Internet Identity. Do not use y
130130

131131
`make init-local II_PRINCIPAL=<YOUR II PRINCIPAL>`
132132

133-
### Step 10: Refresh the web browser to verify that your tokens were deposited.
133+
### Step 10: Refresh the web browser to verify that your tokens were deposited.
134134

135135
To trade tokens with yourself, you can open a second incognito browser window.
136136

archive/motoko/defi/architecture.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ To enable DEFI application on the IC, canisters need to interact with token cani
44

55
## Architecture
66

7-
The design of the IC allows for more complex on-chain computation. In combination with cheap storage, it is possible to have on-chain order books. This example takes advantage of these features and stores user balances and orders inside the exchange canister. The example exchange functionality can be condensed into the following steps:
7+
The design of the IC allows for more complex onchain computation. In combination with cheap storage, it is possible to have onchain order books. This example takes advantage of these features and stores user balances and orders inside the exchange canister. The example exchange functionality can be condensed into the following steps:
88

99
1. Exchange takes custody of funds (different mechanism for tokens and ICP, see below).
1010
2. Exchange updates internal balance book.
@@ -13,7 +13,7 @@ The design of the IC allows for more complex on-chain computation. In combinatio
1313

1414
### Interface
1515

16-
Request user-specific ledger account identifier from the exchange. This unique account identifier represents a user-specific subaccount in the exchange's ledger account, allowing it to differentiate between user deposits.
16+
Request user-specific ledger account identifier from the exchange. This unique account identifier represents a user-specific subaccount in the exchange's ledger account, allowing it to differentiate between user deposits.
1717
```
1818
getDepositAddress: () -> (blob);
1919
```
@@ -25,7 +25,7 @@ Withdraw request to the exchange. The exchange will send funds back to the user
2525
```
2626
withdraw: (Token, nat, principal) -> (WithdrawReceipt);
2727
```
28-
Place new order to exchange. If the order matches an existing order, it will get executed.
28+
Place new order to exchange. If the order matches an existing order, it will get executed.
2929
```
3030
placeOrder: (Token, nat, Token, nat) -> (OrderPlacementReceipt);
3131
```
@@ -72,5 +72,5 @@ Compared to depositing funds, withdrawing funds is simpler. Since the exchange h
7272
## Common mistakes
7373

7474
- **Concurrent execution**: If canister functions have `await` statements, it is possible that execution is interleaved. To avoid bugs, it is necessary to carefully consider the placement of data structure updates to prevent double-spend attacks.
75-
- **Floating Points**: More advanced exchanges should take care of floating points and make sure to limit decimals.
75+
- **Floating Points**: More advanced exchanges should take care of floating points and make sure to limit decimals.
7676
- **No panics after await**: When a panic happens, the state gets rolled back. This can cause issues with the correctness of the exchange.
+87
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
// This is the official Ledger interface that is guaranteed to be backward compatible.
2+
3+
// Amount of tokens, measured in 10^-8 of a token.
4+
type Tokens = record {
5+
e8s : nat64;
6+
};
7+
8+
// Number of nanoseconds from the UNIX epoch in UTC timezone.
9+
type TimeStamp = record {
10+
timestamp_nanos: nat64;
11+
};
12+
13+
// AccountIdentifier is a 32-byte array.
14+
// The first 4 bytes is big-endian encoding of a CRC32 checksum of the last 28 bytes.
15+
type AccountIdentifier = blob;
16+
17+
// Subaccount is an arbitrary 32-byte byte array.
18+
// Ledger uses subaccounts to compute the source address, which enables one
19+
// principal to control multiple ledger accounts.
20+
type SubAccount = blob;
21+
22+
// Sequence number of a block produced by the ledger.
23+
type BlockIndex = nat64;
24+
25+
// An arbitrary number associated with a transaction.
26+
// The caller can set it in a `transfer` call as a correlation identifier.
27+
type Memo = nat64;
28+
29+
// Arguments for the `transfer` call.
30+
type TransferArgs = record {
31+
// Transaction memo.
32+
// See comments for the `Memo` type.
33+
memo: Memo;
34+
// The amount that the caller wants to transfer to the destination address.
35+
amount: Tokens;
36+
// The amount that the caller pays for the transaction.
37+
// Must be 10000 e8s.
38+
fee: Tokens;
39+
// The subaccount from which the caller wants to transfer funds.
40+
// If null, the ledger uses the default (all zeros) subaccount to compute the source address.
41+
// See comments for the `SubAccount` type.
42+
from_subaccount: opt SubAccount;
43+
// The destination account.
44+
// If the transfer is successful, the balance of this address increases by `amount`.
45+
to: AccountIdentifier;
46+
// The point in time when the caller created this request.
47+
// If null, the ledger uses current IC time as the timestamp.
48+
created_at_time: opt TimeStamp;
49+
};
50+
51+
type TransferError = variant {
52+
// The fee that the caller specified in the transfer request was not the one that ledger expects.
53+
// The caller can change the transfer fee to the `expected_fee` and retry the request.
54+
BadFee : record { expected_fee : Tokens; };
55+
// The account specified by the caller doesn't have enough funds.
56+
InsufficientFunds : record { balance: Tokens; };
57+
// The request is too old.
58+
// The ledger only accepts requests created within 24 hours window.
59+
// This is a non-recoverable error.
60+
TxTooOld : record { allowed_window_nanos: nat64 };
61+
// The caller specified `created_at_time` that is too far in future.
62+
// The caller can retry the request later.
63+
TxCreatedInFuture : null;
64+
// The ledger has already executed the request.
65+
// `duplicate_of` field is equal to the index of the block containing the original transaction.
66+
TxDuplicate : record { duplicate_of: BlockIndex; }
67+
};
68+
69+
type TransferResult = variant {
70+
Ok : BlockIndex;
71+
Err : TransferError;
72+
};
73+
74+
// Arguments for the `account_balance` call.
75+
type AccountBalanceArgs = record {
76+
account: AccountIdentifier;
77+
};
78+
79+
service : {
80+
// Transfers tokens from a subaccount of the caller to the destination address.
81+
// The source address is computed from the principal of the caller and the specified subaccount.
82+
// When successful, returns the index of the block containing the transaction.
83+
transfer : (TransferArgs) -> (TransferResult);
84+
85+
// Returns the amount of Tokens on the specified account.
86+
account_balance : (AccountBalanceArgs) -> (Tokens) query;
87+
}

rust/defi/README.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ The sample exchange is implemented in [Motoko](https://github.com/dfinity/exampl
88

99
## Architecture
1010

11-
The design of the IC allows for more complex on-chain computation. In combination with cheap storage, it is possible to have on-chain order books. This sample code takes advantage of these features and stores user balances and orders inside the exchange canister. The sample exchange functionality can be condensed into the following steps:
11+
The design of the IC allows for more complex onchain computation. In combination with cheap storage, it is possible to have onchain order books. This sample code takes advantage of these features and stores user balances and orders inside the exchange canister. The sample exchange functionality can be condensed into the following steps:
1212

1313
- Exchange takes custody of funds (different mechanism for tokens and ICP, see below).
1414

@@ -72,7 +72,7 @@ There are a number of token standards in development (e.g. IS20, DFT, and DRC20)
7272

7373
### Placing orders
7474

75-
After depositing funds to the exchange, the user can place orders. An order consists of two tuples. `from: (Token1, amount1)` and `to: (Token2, amount2)`. These orders get added to the exchange. What happens to these orders is specific to the exchange implementation. This sample provides a simple exchange that only executes exactly matching orders. Be aware this is just a toy exchange, and the exchange functionality is just for completeness.
75+
After depositing funds to the exchange, the user can place orders. An order consists of two tuples. `from: (Token1, amount1)` and `to: (Token2, amount2)`. These orders get added to the exchange. What happens to these orders is specific to the exchange implementation. This sample provides a simple exchange that only executes exactly matching orders. Be aware this is just a toy exchange, and the exchange functionality is just for completeness.
7676

7777
### Withdrawing funds
7878

@@ -107,7 +107,7 @@ or you can regenerate the URL "http://127.0.0.1:4943?canisterId=$(dfx canister i
107107

108108
## Step 2: To interact with the exchange, you can create a local Internet Identity by clicking the login button.
109109

110-
This sample project uses a local test version of Internet Identity. Do not use your mainnet Internet Identity, and this testnet Internet Identity will not work on the mainnet.
110+
This sample project uses a local test version of Internet Identity. Do not use your mainnet Internet Identity, and this testnet Internet Identity will not work on the mainnet.
111111

112112

113113
## Step 3: When prompted, select **Create Internet Identity**.
@@ -132,7 +132,7 @@ This sample project uses a local test version of Internet Identity. Do not use y
132132

133133
`make init-local II_PRINCIPAL=<YOUR II PRINCIPAL>`
134134

135-
## Step 10: Refresh the web browser to verify that your tokens were deposited.
135+
## Step 10: Refresh the web browser to verify that your tokens were deposited.
136136

137137

138138
To trade tokens with yourself, you can open a second incognito browser window.

rust/dip721-nft-container/README.md

+7-7
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
keywords: [advanced, rust, nft, dip721]
33
---
44

5-
# DIP721 NFT
5+
# DIP721 NFT
66

77
[View this sample's code on GitHub](https://github.com/dfinity/examples/tree/master/rust/dip721-nft-container)
88

@@ -47,7 +47,7 @@ In case an error occurs during any part of the upgrade (including `post_upgdrade
4747

4848
The Rust CDK (Canister Development Kit) currently only supports one value in stable memory, so it is necessary to create an object that can hold everything you care about.
4949
In addition, not every data type can be stored in stable memory; only ones that implement the [CandidType trait](https://docs.rs/candid/latest/candid/types/trait.CandidType.html)
50-
(usually via the [CandidType derive macro](https://docs.rs/candid/latest/candid/derive.CandidType.html)) can be written to stable memory.
50+
(usually via the [CandidType derive macro](https://docs.rs/candid/latest/candid/derive.CandidType.html)) can be written to stable memory.
5151

5252
Since the state of our canister includes an `RbTree` which does not implement the `CandidType`, it has to be converted into a data structure (in this case a `Vec`) that implements `CandidType`.
5353
Luckily, both `RbTree` and `Vec` implement functions that allow converting to/from iterators, so the conversion can be done quite easily.
@@ -76,7 +76,7 @@ For a much more detailed explanation of how certification works, see [this expla
7676
- **Operator**: sort of a delegated owner. The operator does not own the NFT but can do the same actions an owner can do.
7777
- **Custodian**: creator of the NFT collection/canister. They can do anything (transfer, add/remove operators, burn, and even un-burn) to NFTs, but also mint new ones or change the symbol or description of the collection.
7878

79-
The NFT example canister keeps access control in these three levels very simple:
79+
The NFT example canister keeps access control in these three levels very simple:
8080
- For every level of control, a separate list (or set) of principals is kept.
8181
- Those three levels are then manually checked every single time someone attempts to do something for which they require authorization.
8282
- If a user is not authorized to call a certain function an error is returned.
@@ -111,7 +111,7 @@ cd examples/rust/dip721-nft-container
111111
dfx start --background --clean
112112
```
113113

114-
### Step 3: Install the canister.
114+
### Step 3: Install the canister.
115115

116116
Deploy the canister with the command:
117117
```sh
@@ -145,9 +145,9 @@ The canister also supports a certified HTTP interface; going to `/<nft>/<id>` wi
145145

146146
Remember that query functions are uncertified; the result of functions like `ownerOfDip721` can be modified arbitrarily by a single malicious node. If queried information is depended on, for example, if someone might send ICP to the owner of a particular NFT to buy it from them, those calls should be performed as update calls instead. You can force an update call by passing the `--update` flag to `dfx` or using the `Agent::update` function in `agent-rs`.
147147

148-
### Step 5: Mint an NFT.
148+
### Step 5: Mint an NFT.
149149

150-
Due to size limitations on the length of a terminal command, an image- or video-based NFT would be impossible to send via `dfx`. To that end, there is an experimental [minting tool](https://github.com/dfinity/experimental-minting-tool) you can use to mint a single-file NFT.
150+
Due to size limitations on the length of a terminal command, an image- or video-based NFT would be impossible to send via `dfx`. To that end, there is an experimental [minting tool](https://github.com/dfinity/experimental-minting-tool) you can use to mint a single-file NFT.
151151

152152
To use this tool, install the minting tool with the command:
153153

@@ -165,7 +165,7 @@ The output of this command should look like this:
165165
Successfully minted token 0 to x4d3z-ufpaj-lpxs4-v7gmt-v56ze-aub3k-bvifl-y4lsq-soafd-d3i4k-fqe (transaction id 0)
166166
```
167167

168-
Minting is restricted to anyone authorized with the `custodians` parameter or the `set_custodians` function. Since the contents of `--file` are stored on-chain, it's important to prevent arbitrary users from minting tokens, or they will be able to store arbitrarily-sized data in the contract and exhaust the canister's cycles. Be careful not to upload too much data to the canister yourself, or the contract will no longer be able to be upgraded afterward.
168+
Minting is restricted to anyone authorized with the `custodians` parameter or the `set_custodians` function. Since the contents of `--file` are stored onchain, it's important to prevent arbitrary users from minting tokens, or they will be able to store arbitrarily-sized data in the contract and exhaust the canister's cycles. Be careful not to upload too much data to the canister yourself, or the contract will no longer be able to be upgraded afterward.
169169

170170
#### Demo
171171

rust/face-recognition/src/frontend/src/index.html

+2-2
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44
<head>
55
<meta charset="UTF-8" />
66
<meta name="viewport" content="width=device-width" />
7-
<title>On-chain ICP face recognition</title>
7+
<title>Onchain ICP face recognition</title>
88
<base href="/" />
99
<link rel="icon" href="favicon.ico" />
1010
<link type="text/css" rel="stylesheet" href="main.css" />
@@ -13,7 +13,7 @@
1313

1414
<body>
1515
<div class="container">
16-
<h1>On-chain ICP <img id="inline-logo" src="logo_small.png"></img> face recognition</h1>
16+
<h1>Onchain ICP <img id="inline-logo" src="logo_small.png"></img> face recognition</h1>
1717
<div>
1818
<label id="filelabel" for="file" class="clickable">
1919
<div id="camera">

svelte/svelte-motoko-starter/README.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ This repository is meant to give [Svelte](https://svelte.dev/) developers an eas
66

77
This template contains:
88

9-
- A Svelte frontend app under `src/frontend` to be hosted on-chain, with support for authentication using Internet Identity.
9+
- A Svelte frontend app under `src/frontend` to be hosted onchain, with support for authentication using Internet Identity.
1010
- A Motoko dapp under `src/backend` to serve as a backend to the Svelte frontend.
1111

1212
You can see a deployed version of this template here: https://zixfv-4yaaa-aaaam-aaatq-cai.ic0.app/
@@ -188,7 +188,7 @@ dfx deploy --network ic
188188

189189
The command will build the project, create a new canister on ICP and deploy the Svelte app into it. The command will also create a new file `canister_ids.json` which will help the dfx tool deploy to the same canister in future updates. You can commit this file in your repository.
190190

191-
You can now open your Svelte app running on-chain. You can find the canister ID in the deploy command output, or use the ID in `canister_ids.json`.
191+
You can now open your Svelte app running onchain. You can find the canister ID in the deploy command output, or use the ID in `canister_ids.json`.
192192

193193
The link to your app is `<canister_id>.ic0.app`. For example, if your canister ID is `zgvi5-hiaaa-aaaam-aaasq-cai`, your app will be at `https://zgvi5-hiaaa-aaaam-aaasq-cai.ic0.app/`.
194194

svelte/svelte-starter/README.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44

55
This repository is meant to give [Svelte](https://svelte.dev/) developers an easy on-ramp to get started with developing decentralized applications (Dapps in short) for ICP. Dapps, also known as smart contracts, are specialized software that runs on a blockchain.
66

7-
This template contains a Svelte app under `src/frontend` that can be hosted on-chain on ICP.
7+
This template contains a Svelte app under `src/frontend` that can be hosted onchain on ICP.
88

99
You can see a deployed version of this template here: https://zgvi5-hiaaa-aaaam-aaasq-cai.ic0.app/
1010

@@ -119,6 +119,6 @@ dfx deploy --network ic
119119

120120
The command will build the project, create a new canister on ICP and deploy the Svelte app into it. The command will also create a new file `canister_ids.json` which will help the dfx tool deploy to the same canister in future updates. You can commit this file in your repository.
121121

122-
You can now open your Svelte app running on-chain. You can find the canister ID in the deploy command output, or use the ID in `canister_ids.json`.
122+
You can now open your Svelte app running onchain. You can find the canister ID in the deploy command output, or use the ID in `canister_ids.json`.
123123

124124
The link to your app is `<canister_id>.ic0.app`. For example, if your canister ID is `zgvi5-hiaaa-aaaam-aaasq-cai`, your app will be at `https://zgvi5-hiaaa-aaaam-aaasq-cai.ic0.app/`.

0 commit comments

Comments
 (0)