Skip to content

Commit

Permalink
Update README
Browse files Browse the repository at this point in the history
  • Loading branch information
SoraSuegami committed Oct 23, 2024
1 parent 83120c8 commit 102ebc6
Showing 1 changed file with 23 additions and 59 deletions.
82 changes: 23 additions & 59 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,68 +1,32 @@
# ic_dns_oracle
## Introduction
This is an ICP canister that generates a signature for a pair of a domain and a hash of a DKIM public key registered on the distributed name service (DNS).
The signature can be verified on Ethereum, allowing smart contracts on Ethereum to verify that the given domain and public key hash are registered on the DNS.
For example, this is used in ZK Email to update a dkim registry contract, which stores the authorized public key hashes accessed during email proof verification.

Our repository contains the implementations of theee canisters as follows:
- Poseidon hash canister: this simply computes the Poseidon hash of the given RSA public key.
- DNS client canister: this fetches an RSA public key for the given selector and domain from Google DNS.
- IC DNS oracle backend canister: this is our main canister that generates an ECDSA signature for the fetched public key corresponding to the given selector and domain. The output signature can be verified by smart contracts on Ethereum.

## How to try our canister
Our IC DNS oracle backend canister is available at https://a4gq6-oaaaa-aaaab-qaa4q-cai.raw.icp0.io/?id=fxmww-qiaaa-aaaaj-azu7a-cai.
For example, by calling the `sign_dkim_public_key` with passing 20230601 and gmail.com as the first and second arguments, respectively, you can obtain the signature for the hash of the public key registered on DNS for the pair of the selector 20230601 and the domain gmail.com.
You can verify it as the ECDSA signature from 0x6293a80bf4bd3fff995a0cab74cbf281d922da02, which is the signer's Ethereum address output by the `get_signer_ethereum_address` function.

## How to run tests
First of all, you need to prepare the binary of `pocket-ic` according to the instruction [here](https://github.com/dfinity/pocketic?tab=readme-ov-file#download-the-pocketic-server).
After you put the binary under the `ic-dns-oracle` directory or set the `POCKET_IC_BIN` to the path to that binary, you can run tests by the following commands:
```
cargo build --target wasm32-unknown-unknown --release
Welcome to your new ic_dns_oracle project and to the internet computer development community. By default, creating a new project adds this README and some template files to your project directory. You can edit these template files to customize your project and to include your own code to speed up the development cycle.

To get started, you might want to explore the project directory structure and the default configuration file. Working with this project in your development environment will not affect any production deployment or identity tokens.

To learn more before you start working with ic_dns_oracle, see the following documentation available online:
cargo test
```

## References
- [Quick Start](https://internetcomputer.org/docs/quickstart/quickstart-intro)
- [SDK Developer Tools](https://internetcomputer.org/docs/developers-guide/sdk-guide)
- [Rust Canister Devlopment Guide](https://internetcomputer.org/docs/rust-guide/rust-intro)
- [ic-cdk](https://docs.rs/ic-cdk)
- [ic-cdk-macros](https://docs.rs/ic-cdk-macros)
- [Candid Introduction](https://internetcomputer.org/docs/candid-guide/candid-intro)
- [JavaScript API Reference](https://erxue-5aaaa-aaaab-qaagq-cai.raw.icp0.io)

If you want to start working on your project right away, you might want to try the following commands:

```bash
cd ic_dns_oracle/
dfx help
dfx canister --help
```

## Running the project locally

If you want to test your project locally, you can use the following commands:

```bash
# Starts the replica, running in the background
dfx start --background

# Deploys your canisters to the replica and generates your candid interface
dfx deploy
```

Once the job completes, your application will be available at `http://localhost:4943?canisterId={asset_canister_id}`.

If you have made changes to your backend canister, you can generate a new candid interface with

```bash
npm run generate
```

at any time. This is recommended before starting the frontend development server, and will be run automatically any time you run `dfx deploy`.

If you are making frontend changes, you can start a development server with

```bash
npm start
```

Which will start a server at `http://localhost:8080`, proxying API requests to the replica at port 4943.

### Note on frontend environment variables

If you are hosting frontend code somewhere without using DFX, you may need to make one of the following adjustments to ensure your project does not fetch the root key in production:

- set`DFX_NETWORK` to `production` if you are using Webpack
- use your own preferred method to replace `process.env.DFX_NETWORK` in the autogenerated declarations
- Setting `canisters -> {asset_canister_id} -> declarations -> env_override to a string` in `dfx.json` will replace `process.env.DFX_NETWORK` with the string in the autogenerated declarations
- Write your own `createActor` constructor


## Automated Monitoring of Cycles
To automate monitoring cycles for your canisters, you can use [cycleops](https://cycleops.dev).
Once you deposit some ICP into a canister for this website, it will automatically fill cycles when the balance of your canister is less than a threshold.
Please use canister ids in `canister_ids.json` after you deploy your canisters.

0 comments on commit 102ebc6

Please sign in to comment.