Forem: Kristofer

Build Multi Chain Applications with IC-Alloy and the Internet Computer

Kristofer — Tue, 17 Dec 2024 21:37:49 +0000

One of the major strengths the Internet Computer (ICP) has over other blockchains is its ability to hold Ethereum, Bitcoin, and other assets natively. Not only can ICP smart contracts hold these assets, but they can also interact with smart contracts on other chains.

IC-Alloy is a fork of the Rust-based Ethereum support library Alloy. The goal of IC-Alloy is to vastly simplify interactions with EVM-based blockchains from the Internet Computer.

In this article, we will explore the features of the IC-Alloy library, how you can use it to interact with Ethereum, and what kind of Chain Fusion use cases it enables.

TL;DR:

IC-Alloy extends Alloy with the following features:

ICP Transport Layer: Routes requests through the IC EVM RPC canister or an external RPC proxy.
ICP Signer: Abstracts away the complexity of signing EVM messages and transactions on ICP.
ICP Provider: Provides a simple interface for interacting with the IC EVM RPC canister.

IC-Alloy has examples!

ic-alloy-toolkit: A collection of examples on how to perform common EVM operations. Live demo
ic-alloy-basic-wallet: A basic Ethereum multi-user wallet. Live demo
ic-alloy-dca: A semi-autonomous agent, swapping tokens on Uniswap for you.

Introduction

Before we dive into the details of IC-Alloy, let's first talk about what we mean when we say that ICP can hold assets natively on other chains.

What Does It Mean to Hold Assets on a Blockchain?

Basics first, here is a refresher on what it means to hold assets on a blockchain. If you are a seasoned blockchain developer you might consider skipping this section.

When you hold an asset on a blockchain, it means you have a balance connected to an address that you control. The address is derived from a cryptographic hash of a public key, while the balance is simply a number representing the amount of the asset you own.

The balance is recorded on the blockchain’s ledger, and you can transfer it to other addresses by signing transactions with your private key. Whoever controls the private key linked to an address effectively controls the assets at that address.

Each blockchain uses a cryptographic scheme that defines how keys and addresses are generated, how messages are signed, and how signatures are verified.

The key to ICP being able to hold assets natively on other chains is that ICP supports more than one cryptographic scheme! In addition to the scheme used by ICP itself, ICP also supports the following schemes:

ECDSA: This scheme allows ICP smart contracts to securely hold Bitcoin and interact with Ethereum and other EVM chains such as Avalanche, Cardano, Cosmos, Dogecoin, Filecoin, Hedera, Polkadot, Stacks, and XRP.
BIP340: A scheme used in Bitcoin, especially in Taproot-related protocols like Ordinals, Runes, and BRC-20 tokens.
Ed25519: A scheme used in Solana, Stellar, Toncoin, Cardano, Polkadot, and Ripple.

ICP supports a powerful cryptographic technology called threshold signatures that allows multiple parties to collaboratively sign messages without exposing their private keys. This technology enables ICP smart contracts to securely derive addresses on behalf of users and sign transactions on other blockchains. Users in turn authenticate and interact with these smart contracts to manage their assets.

To learn more about this, check out my recent article: What the Schnorr?! Threshold Signatures on the Internet Computer.

Introducing IC-Alloy

Alloy is a Rust library providing a comprehensive toolset for encoding, decoding, and constructing various Ethereum-specific data types, including transaction and contract objects. Alloy supports the creation of Ethereum-compatible applications by offering developers a type-safe, performant, and ergonomic API for interfacing with Ethereum’s core primitives and executing tasks like building, signing, and decoding transactions.

Alloy is a great library for Rust developers working with Ethereum, but it lacks built-in support for ICP. This is where IC-Alloy comes in.

Luckily, Alloy is designed to be modular and easily extensible. This makes it possible to fork Alloy and add support for ICP without having to rewrite the entire library from scratch.

1. An ICP Transport Layer

Smart contracts on ICP are called "canisters." Canisters are composable and can call each other, making it possible to build complex applications by combining multiple canisters.

To interact with Ethereum, application canisters make calls to the EVM RPC canister. This canister acts as a gateway between the Internet Computer and Ethereum, allowing canisters to send requests to Ethereum's JSON-RPC API and receive responses.

The EVM RPC canister in turn uses another core feature of ICP—HTTPS Outcalls—making it possible for smart contracts to communicate with the outside world.

IC-Alloy adds an ICP Transport Layer to Alloy, abstracting away the complexity of routing requests through the EVM RPC canister or an external RPC proxy. This layer ensures that all requests to Ethereum are routed correctly and that requests and responses are properly typed, serialized, etc.

2. An ICP Signer

Alloy signers are responsible for... you guessed it... signing transactions. Alloy offers some built-in signers for using Ledger and Trezor physical wallets, as well as various software signers for signing transactions in memory where the private key is accessible to the program.

IC-Alloy extends Alloy with an ICP Signer that taps into the threshold signature capabilities of ICP. A canister never has direct access to the private keys used to sign transactions. Instead, the canister sends a request to the subnet nodes, which collaboratively generate the signature using a threshold signing protocol.

3. An ICP Provider

Alloy providers facilitate the interaction with Ethereum by managing JSON-RPC requests and responses. Providers offer utility functions for common tasks like querying the state of a smart contract, sending transactions, and estimating gas costs.

The ICP Provider in IC-Alloy extends the Alloy provider with ICP-specific functionality. For example, ICP canisters cannot easily work with the popular Rust library Tokio, as it is not fully compatible with the Internet Computer. Instead, ICP canisters have to rely on IC timers to do things like waiting for a transaction to be mined or subscribing to log events.

Show Me Some Code Already

Let's do a walkthrough of how to use IC-Alloy to get the balance of an ERC-20 token on Ethereum. This should give you a good idea of how IC-Alloy works and how you can use it in your own projects.

You’ll find more docs, examples, etc., on the IC-Alloy website.

Add IC-Alloy to Your Project

To use the ICP-enabled fork of Alloy in your project, add this to Cargo.toml:

alloy = { git = "https://github.com/ic-alloy/ic-alloy.git", tag = "v0.3.5-icp.0", features = ["icp"]}

Read and Parse the IERC20 Source Code

One of the greatest features of the Alloy library is the sol!() macro that lets you read and parse Solidity source code. This means we can head over to Etherscan and just copy the interfaces we are interested in. Alloy does all the heavy lifting, converting the interfaces into Rust code that we can use in our project.

sol!(
    #[sol(rpc)]
    "sol/IERC20.sol"
);

The `get_balance` function

Before we break down the code, here is the full get_balance function:

#[ic_cdk::update]
async fn get_balance(address: String) -> Result<String, String> {
    let address = address.parse::<Address>().map_err(|e| e.to_string())?;
    let rpc_service = RpcService::EthSepolia(EthSepoliaService::Alchemy);
    let config = IcpConfig::new(rpc_service);
    let provider = ProviderBuilder::new().on_icp(config);

    let usdc = IERC20::new(token_address, provider);

    let result = usdc.balanceOf(address).call().await;
    match result {
        Ok(balance) => Ok(balance._0.to_string()),
        Err(e) => Err(e.to_string()),
    }
}

1. Parse address

let address = address.parse::<Address>().map_err(|e| e.to_string())?;

First, we parse the address string into an Alloy Address type. This ensures that the address is valid and causes the function to return an error if it is not.

2. Create an RPC service

let rpc_service = RpcService::EthSepolia(EthSepoliaService::Alchemy);

Next, we create an RpcService that instructs the EVM RPC canister to use Alchemy as the RPC provider. See the list of RPC providers the EVM RPC canister supports.

3. Create a config object

let config = IcpConfig::new(rpc_service);

The config object determines the behavior of the ICP provider and transport when making the request. The new function takes the RpcService we created in the previous step and uses default values for the other fields.

4. Create a provider

let provider = ProviderBuilder::new().on_icp(config);

The ProviderBuilder is a helper that allows you to create a provider with a specific configuration. In this case, we use the on_icp method to create a provider that uses the ICP transport layer.

5. Creating an instance of the IERC20 contract

let usdc = IERC20::new(token_address, provider);

How great is this!? We can just create an instance of the IERC20 contract by calling the new method on the IERC20 struct. The new method takes the address of the contract and the provider we created in the previous step.

Once set up, we have access to all contract methods defined in the IERC20 interface.

6. Get the balance

let result = usdc.balanceOf(address).call().await;

Finally, we call the balanceOf method on the contract to get the balance of the address. The method returns a Result that we can match on to get the balance or an error.

Building Chain Fusion Applications

You have seen how the threshold signature technology of ICP together with IC-Alloy makes it super easy to interact with Ethereum from ICP smart contracts.

With Internet Computer lingo, we call these multi chain applications “Chain Fusion” applications. By Chain Fusion, we mean applications that seamlessly fuse together blockchains without the need for intermediaries.

Examples of Chain Fusion use cases include:

Decentralized Exchanges (DEXs): Canisters can securely hold assets from multiple chains and facilitate trustless swaps between them.
Cross-Chain Messaging: Canisters can send messages and trigger actions on other chains, enabling complex workflows and interoperability.
Multi-Asset Wallets: Canisters can manage a diverse portfolio of assets across various blockchains, providing users with a unified interface for asset management.
Co-processing and off-chain computation: Canisters can offload heavy computations to other chains and use the results in their own computations.
Autonomous agents and smart contracts: Canisters can act as autonomous agents, interacting with other chains on behalf of users.

IC-Alloy comes with a collection of examples on how to perform common EVM operations, build wallets, and even create autonomous agents:

ic-alloy-toolkit: A collection of examples on how to perform common EVM operations. Live demo
ic-alloy-basic-wallet: A basic Ethereum multi-user wallet. Live demo
ic-alloy-dca: A semi-autonomous agent, swapping ERC-20 tokens on Uniswap for you.

Let's build!

What the Schnorr?! Threshold Signatures on the Internet Computer

Kristofer — Tue, 12 Nov 2024 15:14:21 +0000

The Internet Computer (ICP) recently added support for Threshold Schnorr signatures alongside its existing Threshold ECDSA support.

What is that anyway?! Schnorr what?!

This article explains these complex cryptographic concepts simply, highlighting the use cases they unlock.

TL;DR:

Threshold signatures allow ICP smart contracts (canisters) to securely derive addresses on other blockchains and sign transactions on their behalf.
ICP supports signature schemes compatible with widely used blockchains, including Bitcoin, Ethereum, Solana and more than twenty other chains.
With this support, a canister on ICP can natively hold Bitcoin, Ethereum, and other assets, and sign transactions directly on those chains without intermediaries.

First, let’s understand the basics of threshold signatures, a powerful technology that enables secure, multi-party signing without exposing private keys.

Threshold Signatures: A Primer

In traditional digital signatures, a single private key is used to sign a message, and the corresponding public key can be used to verify the signature. In a blockchain context, the public key is used to derive an address, and the private key is used to sign transactions. If you are using Ledger to interact with a blockchain, the private key is stored on the device. If you use Metamask, the private key is stored in your browser.

In threshold signatures, the private key is instead divided into multiple shares, and a subset of these shares is required to collectively sign a message. This approach offers several advantages:

Enhanced Security: Since no single entity possesses the entire private key, the risk of a single point of failure or compromise is reduced.
Resilience: Even if some key shares are compromised, the threshold number of shares required for signing ensures that the signature remains secure.
Flexibility: Threshold signatures can be used for multi-signature schemes, where multiple parties collectively sign a message, or for threshold schemes where a subset of nodes in a network collaboratively sign transactions.

On ICP, the nodes of the subnet hosting a canister hold the key shares. These nodes are collectively responsible for generating and managing the key shares required for threshold signatures.

Unique Public Keys for Canister Identity and Security

Every canister on the Internet Computer has its own unique public key, acting as its secure identifier. Canisters never have direct access to their private keys, ensuring that sensitive operations remain protected. When a canister needs to sign a transaction or message, it sends a request to the subnet nodes, which collaboratively generate the signature using a threshold signing protocol.

To interact with other blockchains, a canister can derive addresses on those chains based on its public key. This capability allows a canister to hold assets on other chains and even sign transactions directly on their behalf, as long as it supports the same signature scheme.

Public key cryptography uses various forms of mathematical curves to generate keys and signatures. On top of these curves, different signature schemes are built, each with its own encoding and security properties. A cryptographic scheme defines how keys are generated, how messages are signed, and how signatures are verified.

Let’s explore the two signature schemes supported by ICP and the blockchains they enable canisters to interact with.

Threshold ECDSA

The first signature scheme supported by ICP was Threshold ECDSA. This scheme allows canisters to securely hold Bitcoin, interact with Ethereum and other EVM chains, and sign transactions on these chains using ECDSA signatures.

ECDSA relies on the elliptic curve secp256k1, a curve chosen for its efficiency and security in cryptographic applications. Developed by the Standards for Efficient Cryptography Group (SECG), secp256k1 was selected by Bitcoin’s creator, Satoshi Nakamoto, for its strong security properties and computational efficiency, making it ideal for digital signatures. Its designation as a Koblitz curve means it has certain mathematical properties that optimize performance, especially for fast computation, which is crucial in high-transaction environments like Bitcoin. The curve’s 256-bit length offers robust protection, balancing security with practical speed for modern cryptographic needs.

Many other chains also build on ECDSA, making it a widely used signature scheme in the blockchain space. Some other chains that use ECDSA include: Avalanche, Cardano, Cosmos, Dogecoin, Filecoin, Hedera, Polkadot, Stacks and XRP.

Learn more about Threshold ECDSA

Threshold Schnorr

With the recent introduction of threshold Schnorr signature scheme, ICP expands its cryptographic capabilities by enabling canisters to sign messages on two different curves: secp256k1 (following BIP340 standards) and Curve25519. This allows for even greater flexibility and compatibility across blockchain ecosystems.

Curve25519 is a slightly newer elliptic curve that offers similar security properties to secp256k1 but with different performance characteristics. It’s optimized for both speed and security, making it efficient and resistant to certain implementation vulnerabilities. Curve25519’s structure also makes it faster for verification, making it ideal for high-performance applications.

Threshold Schnorr on ICP supports two main algorithms, each with its own signature encoding:

BIP340 on secp256k1: This curve and encoding are widely used in Bitcoin, especially in Taproot-related protocols like Ordinals, Runes, and BRC-20 tokens. This compatibility allows ICP canisters to directly interact with Bitcoin’s Taproot features.
Ed25519: Ed25519 is a signature scheme that builds on Curve25519, using it in the Edwards form. This option provides compatibility with protocols and ecosystems that rely on Ed25519-based signatures. Ed25519 is a specific implementation of EdDSA (Edwards-curve Digital Signature Algorithm), a more general signature scheme known for its strong security and high performance.

Offering EdDSA opens up support for a wide range of additional chains, including Solana, Stellar, Toncoin, Cardano, Polkadot, and Ripple.

Learn more about Threshold Schnorr

Putting Threshold Signatures to Work

Let's wrap up this short article.

You have learnt how threshold signatures allow ICP canisters to interact natively with other blockchains, securely holding assets and signing transactions. This capability opens up a world of possibilities for decentralized applications and cross-chain interactions.

Using Internet Computer lingo, we call this capability “chain fusion”, where different blockchains can seamlessly interact and share assets without the need for intermediaries.

Examples of chain fusion use cases include:

Decentralized Exchanges (DEXs): Canisters can securely hold assets from multiple chains and facilitate trustless swaps between them.
Cross-Chain Messaging: Canisters can send messages and trigger actions on other chains, enabling complex workflows and interoperability.
Multi-Asset Wallets: Canisters can manage a diverse portfolio of assets across various blockchains, providing users with a unified interface for asset management.

Conclusion

Chain fusion and threshold signatures are exciting developments promising a future where blockchains can seamlessly interact and share assets in a trustless, secure manner. With support for both Threshold ECDSA and Threshold Schnorr signatures, the Internet Computer now supports most major blockchains.

The internetcomputer.org website provides detailed documentation on how to implement threshold signatures in your smart contracts.

Let's build!

Introducing: Composite Attestations Engine (CATTS)

Kristofer — Wed, 20 Mar 2024 09:47:11 +0000

This article introduces the concept of composite attestations and the Composite Attestations Engine (CATTS). It gives a high level overview of the concept and a draft of the planned features of the engine.

TL;DR

Composite attestations are a new type of Ethereum attestation combining data from multiple sources to form a unified and verifiable credential.
Use cases include:
- Transforming attestations from one type to another
- Bridging attestations between EVM chains
- Make ETH attestations available to non EVM chains (ICP, Solana)
CATTS have not been implemented yet, the project will be built during Q2, 2024.
Follow CATTS! Telegram - CATTS Community

Introduction
Planned features
Future features
Flow
Recipe
Composite Attestation
Receipt
Example run: User has attestation 1 AND attestation 2

Introduction

The Ethereum Attestation Service (EAS) is an infrastructure public good for making attestations onchain or offchain about anything. Attestations can represent identity, reputation, knowledge, and much more. EAS is a tokenless and free service that is available on mainnet, several L2s, and various testnets. EAS is a great service! It is tokenless and free for anyone to use. This means it is being used. A lot!

There is a universe of attestation data out there. EAS provides an API that allows you to query that data which makes integration into websites and apps easy.

Let's say I, as an app, want to offer membership to users that meet certain criteria. I my backend, I can use the EAS API to query all attestations that are relevant to my use case. Then, I write some custom logic to process the data and let the outcome of that logic determine if a user is eligible for membership. Easy!

But, what if I need to show a proof of the outcome of my logic? What if I need to create an attestation that says "This user is eligible for membership"? I can of course easily create that attestation. But, without knowledge of the data I processed or about the processing logic I ran on the data, how can anyone verify that the attestation I created is correct?

Wouldn't it be great if there was a way to create attestations based on the result of custom queries and processing logic and have the result of that logic be independently verifiable? That's where CATTS, the Composite Attestations Engine comes in.

CATTS allows for the creation of composite attestations based on custom queries and processing logic. Running on the Internet Computer (ICP) as a smart contract canister, it leverages data from existing attestations via the EAS GraphQL API, ensuring that the creation and verification of attestations are both reliable and transparent. The processing logic is defined as a piece of arbitrary JavaScript code, which is executed securely within the canister environment. The engine also provides a receipt for each run, detailing the settings used, which aids in verifying the correctness of the composite attestations.

Planned features

Custom queries: Fetch data from the EAS GraphQL API using custom queries.
Custom processing logic: Define custom processing logic to create composite attestations based on the result of the queries.
Secure execution: The processing logic is executed securely within the canister environment.
Receipts: A receipt is created for each run, detailing the settings used, which aids in verifying the correctness of the composite attestations.
Chain agnostic: Run queries on one chain or on multiple chains.
Verifiable: The result of the processing logic is independently verifiable.
Open: The engine is open source and free to use. Anyone can create and run recipes.
Cost effective: Attestation runs can be simulated before they are run. This ensures that the cost of running the canister is minimized.

Future features

Advanced settings:
- Allow query chain settings to be overridden on a per run and per query basis.
Allow users to "claim" their composite attestations:
- Transfers cost of creating attestations to the user.
- Allow the user to claim an attestation using multiple addresses.
Even more chain agnostic:
- Allow the creation of attestations on multiple chains.
- Allow querying other attestation services, not just EAS.
ZK attestations:
- Allow the creation of zero knowledge attestations.

Flow

The flow of creating composite attestations using CATTS is as follows:

Create recipe: Define a recipe that includes custom queries, processing logic and output schema.
Simulate run: Simulate the run to verify the correctness of the recipe. Queries are run in the browser at no cost. A run can be simulated many times during the recipe creation process.
Run: Running the recipe means that the CATTS engine executes all queries and process the result set according to the processing instructions. The run output is saved and a run receipt is created as an attestation.
Create attestations: The CATTS engine creates attestations based on the run output and the output schema.

Recipe

The CATTS recipe is a set of instructions that CATTS uses to create attestations. The recipe is in itself an attestation, consisting of the following parts:

Queries
Query variables
Query settings
Processor
Output schema

Queries

A query fetches data from the EAS GraphQL API.
Queries are executed in the canister as HTTPS outcalls.
The result of a query is determined by the query itself and the query variables.

Example:

query Query($where: AttestationWhereInput) {
  attestations(where: $where) {
    recipient
  }
}

The above query will return all the recipients of attestations that match the criteriea defined in the where variable.

Query variables

All variables that are allowed by the EAS GraphQL API schema are allowed in the recipe.
Every query can have its own set of variables.
Variables cannot be overridden on a per run basis. This might be a feature in future iterations.

Example:

[
  "where": {
    "schemaId": {
      "equals": "0xCBA...321"
    },
  },
]

The above query and variable will return all the receipents of all attestations that have been created using the schema with UID 0xCBA...321.

Query settings

Every query can have its own settings.
In the first iteration, the settings available are limited. In future iterations, more advanced settings will be available.
Settings:
- chain: number - The chain to run the query on.

Processor

After running the queries, we want to process the result set to create aggregate attestations using arbitrary logic.
The logic expresses what we want to create attestations for.
Processors are run in the canister. This is a key feature of CATTS. Running the processor in the canister ensures that the processor is run in a secure environment and that we can trust the result of the processor.
Processors are written in JavaScript.

Example, imagine a Javascript function that performs the following logic:

Process the data set and return only those recipients that have attestations for 
"is a human" and "has a gitcoin passport score of 30 or more".

Output schema

The output schema is a Attestation schema that is used to create attestations based on the result of the processor.
Schemas are defined outside of EEA and are referenced by UID.
Schema:
- UID: string - UID referencing an EAS schema.
- chain: number - The chain to create the attestations on.

Composite Attestation

A composite attestation is an attestation that is created based on the result of the processor. The attestations are created by the CATTS canister.

Every attestation references the "run receipt" attestation in the "referenced attestation" field.
The CATTS canister has to pay for the attestations it creates. This cost is passed on to the user that is making the run. The cost is determined by the number of attestations that are created and the chain that the attestations are created on.

Receipt

A run receipt is created for every run, as a way to verify the correctness of the composite attestations. The receipt is created as an attestation on the same chain as the attestations that were created.

All receipts use the same predefined schema.
Schema:
- recipe_uid: string - The UID of the recipe that was run.
- data_raw: any[] - The raw data that was returned from the queries.
- data_processed: any[] - The data that was returned from the processor.
- timestamp: number - The timestamp of the run.
- initiator: string (ethereum address) - The address that initiated the run.

Example run: User has attestation 1 AND attestation 2

The below example shows how to create a composite attestation for a user that has both attestation 1 and attestation 2.

Recipe

Query

Fetch all recipients of attestations, determined by the where1 and where2 variables.

query Query1($where1: AttestationWhereInput) {
  attestations(where: $where1) {
    recipient
  }
}
query Query2($where2: AttestationWhereInput) {
  attestations(where: $where2) {
    recipient
  }
}

Query variables

The above query and variable will return all the receipents of all attestations that have been created using the schema with UID 0xCBA...321 and 0xABC...123.

{
  "where1": {
    "schemaId": {
      "equals": "0xCBA...321"
    },
  },
  "where2": {
      "schemaId": {
      "equals": "0xABC...123"
    },
  },
}

Query settings

Note the chain setting. In the first query, we are running the query on chain 1, and in the second query, we are running the query on chain 10.

{
  "Query1": {
    "chain": 1
  },
  "Query2": {
    "chain": 10
  }
}

Processor

Create a merged list with addresses that exist in query 1 and 2:

function process(data) {
  const recipientsQuery1 = data.Query1.map(item => item.recipient);
  const recipientsQuery2 = data.Query2.map(item => item.recipient);
  return recipientsQuery1.filter(recipient => recipientsQuery2.includes(recipient));
}

Output schema

Define the composite attestation schema as follows:

{
  "UID": "0x123...456",
  "schema": [
    {
      "name": "hasAttestation1and2",
      "type": "boolean"
    }
  ]
}

A user that has both attestation 1 and 2 will receive an attestation with the schema 0x123...456 and the data {"hasAttestation1and2": true}.

Run

1. Run queries

Running the two queries return the following result set:

{
  "Query1": [
    { "recipient": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" },
    { "recipient": "0x1E0447b19BB6EcFdAe1e4AE1694b0C3659614e4e" },
    { "recipient": "0x7ED57EdC930333F9130B247797C718234272755F" }
  ],
  "Query2": [
    { "recipient": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" },
    { "recipient": "0xbd0531975D4D273e557E40856320304B39806AD8" },
    { "recipient": "0x7ED57EdC930333F9130B247797C718234272755F" }
  ]
}

2. Run processor

After processing the data, only two addresses remain:

[
  { "recipient": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" },
  { "recipient": "0x7ED57EdC930333F9130B247797C718234272755F" }
]

3. Create attestations

Create attestations for all addresses in the processor result:

{
  "attestations": [
    {
      "recipient": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
      "schema": "0x123...456",
      "data": {
        "hasAttestation1and2": true
      }
    },
    {
      "recipient": "0x7ED57EdC930333F9130B247797C718234272755F",
      "schema": "0x123...456",
      "data": {
        "hasAttestation1and2": true
      }
    }
  ]
}

4. Create run receipt

The run receipt reflects all details of the run and is created as an attestation.

{
  "run": {
    "recipe_uid": "0xabC...867",
    "data_raw": {
      "Query1": [
        { "recipient": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" },
        { "recipient": "0x1E0447b19BB6EcFdAe1e4AE1694b0C3659614e4e" },
        { "recipient": "0x7ED57EdC930333F9130B247797C718234272755F" }
      ],
      "Query2": [
        { "recipient": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" },
        { "recipient": "0xbd0531975D4D273e557E40856320304B39806AD8" },
        { "recipient": "0x7ED57EdC930333F9130B247797C718234272755F" }
      ]
    },
    "data_processed": [
      { "recipient": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" },
      { "recipient": "0x7ED57EdC930333F9130B247797C718234272755F" }
    ],
    "timestamp": 1634025600,
    "initiator": "0xAAA...111"
  }
}

You made it to the end, great work! What's next? Share your feedback with us and join the community!

Telegram - CATTS Community

Create a cross chain ETH/ICP application using Azle and TypeScript

Kristofer — Fri, 16 Feb 2024 08:58:41 +0000

A TypeScript smart contract with a React/Vite frontend using Sign in with Ethereum (SIWE) for authentication.

The Internet Computer (ICP) is a blockchain network designed to host and execute smart contracts, offering a secure and scalable platform for decentralized applications and data storage.

Smart contracts on ICP are called "canisters" and can be written in a variety of programming languages, including Motoko, Rust, C, and now... TypeScript, thanks to Azle.

This article looks at how you can get started building canisters in TypeScript and how you can use Sign in with Ethereum (SIWE) to easily authenticate users. Building cross-chain applications has never been easier!

Before we dig in, let's look more closely at how ICP works and how it differs from other blockchain networks.

ICP runs full-stack applications on the blockchain

ICP introduces a novel approach to blockchain technology, offering a decentralized and serverless cloud infrastructure. Unlike traditional blockchains, ICP employs "canisters", an advanced form of smart contracts, to enable the creation of scalable and tamperproof applications directly on the blockchain. This structure allows for the development of a wide range of applications, from social networks to enterprise systems, without relying on external servers or cloud services. Furthermore, ICP's unique reverse gas model simplifies user interaction with blockchain applications, as it doesn't require users to hold tokens or set up a wallet, making it more accessible and user-friendly compared to other blockchain platforms.

Canisters are compiled to WebAssembly. Once deployed, they can be accessed by users through a web interface or through other canisters. Canisters run in full isolation from each other and can be composed to form larger applications.

Use Azle to write TypeScript canisters

Azle, developed by Demergent Labs, is a significant advancement for the ICP ecosystem, enabling TypeScript developers to write canisters. It achieves feature parity with existing Rust and Motoko CDKs, meaning developers can access almost all IC functionality through TypeScript. This integration not only simplifies the development process for those familiar with TypeScript but also enriches the ICP developer community by incorporating the extensive resources and tools available in the TypeScript ecosystem. Demergent Labs also provides Kybra, a Python based CDK.

One goal of Azle is that you should eventually be able to run virtually any Node.js backend code on ICP. Already today, you can run Express, Apollo Server, SQLite, and many other popular Node.js libraries.

Sign in with Ethereum (SIWE) for cross-chain authentication

The SIWE standard defines a protocol for off-chain authentication of Ethereum accounts. At the core of the protocol is the SIWE message, which is a signed message that contains the Ethereum address of the user and some additional metadata. The SIWE message is signed by the user's Ethereum wallet and then sent to the application's backend. The backend verifies the signature and Ethereum address and then creates a session for the user.

Let's build!

This article is not a follow-along step-by-step tutorial, but rather a guide to get you started building your own cross-chain applications. Instead of providing a full tutorial that would run the risk of becoming too lengthy, I will dive in and explain critical parts of the example repository this article is based on.

The example application allows users to connect their Ethereum wallet and then login using SIWE. After logging in, users can create a user profile with their name and image. This profile is stored in a backend canister. In the frontend of the application, all user profiles are displayed in a list.

The app is composed of three canisters:

ic_siwe_provider - A pre-built canister that provides the SIWE authentication functionality.
backend - The Azle TypeScript canister that stores user profiles and provides an API for the frontend application.
frontend - A React/Vite application that interact with the backend and SIWE provider canisters. Yes, ICP can host frontend applications as well!

You can find the full code for the example application on GitHub: ic-siwe-react-demo-ts.

Install the IC SDK

The IC SDK is the software development kit used for creating and managing canisters. The IC SDK includes dfx, the command-line interface for the SDK. dfx is used to create, build, deploy, and manage canisters. dfx also includes a local replica of the ICP blockchain, which can be used for testing and development.

Install the SDK:

sh -ci "$(curl -fsSL https://internetcomputer.org/install.sh)"

ℹ️ If you are using a machine running Apple silicon, you will need to have Rosetta installed. You can install Rosetta by running softwareupdate --install-rosetta in your terminal.

Clone the example repository

Before you proceed, clone the example repository to your local machine. It includes the full source code for all three canisters.

git clone https://github.com/kristoferlund/ic-siwe-react-demo-ts

Then, navigate to the project directory and install the dependencies:

cd ic-siwe-react-demo-ts
npm install

The project is created as a monorepo and consists of two main packages: frontend and backend. The frontend package is the React/Vite application, and the backend package is the Azle TypeScript canister. The SIWE provider does not get a package of its own, as it is a pre-built canister.

ic-siwe-react-demo-ts
├─ packages
│  ├─ backend
│  │  ├─ src
│  │  ├─ backend.did
│  │  ├─ package.json
│  │  ├─ tsconfig.json
│  ├─ frontend
│  │  ├─ src
│  │  ├─ package.json
│  │  ├─ tsconfig.json
│  │  ├─ vite.config.ts
├─ dfx.json
├─ package.json
├─ Makefile

`dfx.json` configures the project canisters

In the root folder of the project, you will find a file called dfx.json. This file configures the project canisters and their dependencies.

{
  "canisters": {
    "ic_siwe_provider": {
      "type": "custom",
      "candid": "https://github.com/kristoferlund/ic-siwe/releases/download/v0.0.4/ic_siwe_provider.did",
      "wasm": "https://github.com/kristoferlund/ic-siwe/releases/download/v0.0.4/ic_siwe_provider.wasm.gz"
    },
    "backend": {
      "type": "custom",
      "main": "packages/backend/src/index.ts",
      "candid": "packages/backend/backend.did",
      "build": "npx azle backend",
      "wasm": ".azle/backend/backend.wasm",
      "gzip": true
    },
    "frontend": {
      "dependencies": ["backend", "ic_siwe_provider"],
      "source": ["dist"],
      "type": "assets",
      "build": ["npm --prefix packages/frontend run build"]
    }
  },
  "output_env_file": ".env",
  "version": 1
}

Let's break down the dfx.json file:

ic_siwe_provider is the prebuilt canister that provides the SIWE authentication method. The candid and wasm properties point to the canister's interface definition and WebAssembly binary, respectively.
backend points to the Azle TypeScript canister. The candid property points to the canister's interface definition, and the main property points to the canister's entry point. The build property specifies the command to build the canister, and the wasm property points to the canister's WebAssembly binary.
frontend is the assets canister that will host the React/Vite application. The dependencies property specifies that the canister depends on the backend and ic_siwe_provider canisters. The source property points to the directory containing the built frontend assets, and the build property specifies the command to build the frontend assets. The canister type, assets, indicates that the canister will host static assets.

Configure and deploy the `ic_siwe_provider` canister

Building composable applications on ICP is easy thanks to WebAssembly! The functionality to provide Ethereum wallet-based authentication is provided by a Rust library. If we were to build a Rust canister, we could have chosen to integrate the library directly into the canister. However, we are building a TypeScript canister, so that is not possible. Luckily, there is a pre-built canister available that we can use!

By adding the pre-built ic_siwe_provider canister to the dfx.json of an ICP project, we can quickly enable Ethereum wallet-based authentication. Later we will interact with it from our frontend application as well as from our backend canister.

Let's start a local replica of ICP blockchain now and deploy the ic_siwe_provider canister:

dfx start --background

Now, we have a fully functional local replica of the ICP blockchain running in the background!

When deploying the ic_siwe_provider canister, we need to provide it with some settings to tell it how to behave. These settings are located in the Makefile of the project:

create-canisters:
    dfx canister create --all

deploy-provider:
    dfx deploy ic_siwe_provider --argument "( \
        record { \
            domain = \"127.0.0.1\"; \
            uri = \"http://127.0.0.1:5173\"; \
            salt = \"some-random-salt\"; \
            chain_id = opt 1; \
            scheme = opt \"http\"; \
            statement = opt \"Login to the SIWE/IC demo app\"; \
            sign_in_expires_in = opt 300000000000; /* 5 minutes */ \
            session_expires_in = opt 604800000000000; /* 1 week */ \
            targets = opt vec { \
                \"$$(dfx canister id ic_siwe_provider)\"; \
                \"$$(dfx canister id backend)\"; \
            }; \
        } \
    )"

To summarize the settings: We tell the provider canister to create sessions that expire after 1 week, and we tell it that the generated identities will be valid for the backend and ic_siwe_provider canisters. For more in-depth information about the settings, please refer to the ic_siwe_provider documentation.

To deploy the ic_siwe_provider canister, run the following commands:

make create-canisters
make deploy-provider

The first command creates all canisters defined in the dfx.json file. When creating canisters, they are initially empty. The second command deploys the ic_siwe_provider canister and provides it with the settings we defined in the Makefile.

The output should look something like this:

Deployed canisters.
URLs:
  Frontend canister via browser
    frontend: http://127.0.0.1:4943/?canisterId=be2us-64aaa-aaaaa-qaabq-cai
  Backend canister via Candid interface:
    backend: http://127.0.0.1:4943/?canisterId=bw4dl-smaaa-aaaaa-qaacq-cai&id=bd3sg-teaaa-aaaaa-qaaba-cai
    ic_siwe_provider: http://127.0.0.1:4943/?canisterId=bw4dl-smaaa-aaaaa-qaacq-cai&id=br5f7-7uaaa-aaaaa-qaaca-cai

Try clicking on the last link to open the ic_siwe_provider canister in your browser. You should see a simple web interface that allows you to interact with the canister.

The frontend application

With the ic_siwe_provider canister in place, now let's take a look at the frontend application.

There is nothing special about the frontend application, it is 100% a regular React/Vite application. Another great ICP feature is its ability to host web applications built using most frameworks.

`main.tsx`:

To setup the frontend application, we need to wrap the <App /> with a few providers that are used throughout the application.

import { _SERVICE } from "./declarations/ic_siwe_provider/ic_siwe_provider.did";
import { canisterId, idlFactory } from "./declarations/ic_siwe_provider/index";

ReactDOM.createRoot(document.getElementById("root")!).render(
  <React.StrictMode>
    <WagmiConfig config={wagmiConfig}>
      <RainbowKitProvider>
        <SiweIdentityProvider<_SERVICE>
          canisterId={canisterId}
          idlFactory={idlFactory}
        >
          <Actors>
            <App />
          </Actors>
        </SiweIdentityProvider>
      </RainbowKitProvider>
    </WagmiConfig>
    <Toaster />
  </React.StrictMode>
);

We start out by wrapping the <App /> with a WagmiConfig and RainbowKitProvider. These providers are used to interact with the Ethereum wallet of the user.

Find more information RainbowKit here: RainbowKit

The SiweIdentityProvider is used to interact with the ic_siwe_provider canister and to keep track of the user's identity.

Note that we are using the idlFactory and canisterId from a folder called declarations. These declarations are generated by the dfx command line tool. Setting up the SiweIdentityProvider with this information allows it to interact with the ic_siwe_provider canister in a typesafe way.

For more details on the setup of the SiweIdentityProvider, please refer to the ic-use-siwe-identity documentation.

`ic/Actors.tsx`

In the Actors component, we wrap our application with yet another provider. This time, it's the ActorProvider that is used to interact with the backend canister.

import { canisterId, idlFactory } from "../declarations/backend/index";
import { _SERVICE } from "../declarations/backend/backend.did";

export default function Actors({ children }: { children: ReactNode }) {
  const { identity, clear } = useSiweIdentity();

  // ...

  return (
    <ActorProvider<_SERVICE>
      canisterId={canisterId}
      context={actorContext}
      identity={identity}
      idlFactory={idlFactory}
    >
      {children}
    </ActorProvider>
  );
}

Again, we are here using the idlFactory and canisterId from the declarations folder to inform the frontend code about the details of the backend canister.

In addition to that, note that we are using the useSiweIdentity hook to get the user's identity. This hook is provided by the ic-use-siwe-identity package. Connecting the ActorProvider with the user's identity means it can perform authenticated calls on behalf of the user, once authenticated.

For more details on the setup of the ActorProvider, please refer to the ic-use-actor documentation.

`components/profile/EditProfile.tsx`

The last frontend component I want to highlight is the EditProfile component. It is used to create and update user profiles. It is a simple form that allows the user to enter their name and a link to an avatar image.

export default function EditProfile() {
  const { actor } = useActor();

  async function submit(event: FormEvent<HTMLFormElement>) {
    const response = await actor.save_my_profile(name, avatarUrl);

    if (response && "Ok" in response) {
      // Handle success
    } else {
      // Handle error
    }
  }

  return (
    <div >
        <form
          className="flex flex-col items-center w-full gap-5"
          onSubmit={submit}
        >
          {/* ... */}
          <Button type="submit">
            {submitText}
          </Button>
        </form>
      </div>
    </div>
  );
}

What I wanted to show here is the actor.save_my_profile call. This is a call to the backend canister that will save the user's profile. The actor object is provided by the ActorProvider. We access the actor object using the useActor hook.

By connecting the ActorProvider with the backend canister interfaces, we get a fully typed actor object that we can use to interact with the canister.

The IC support libraries together with the useActor hook abstracts away most of the complexity of making authenticated calls to ICP canisters.

Build and deploy the frontend canister

Now, let's go ahead and deploy the frontend! The details for building and deploying are defined in the Makefile:

deploy-frontend:
    npm install
    dfx deploy frontend

Nothing too fancy here, we are simply installing the dependencies and then deploying the frontend canister using the build instructions defined in the dfx.json file. To build and deploy, run the following command:

make deploy-frontend

The backend

Now, let's have a look at the backend canister. The package is setup like a regular TypeScript project, requiring only azle as a dependency. Nice!

package.json:

{
  "dependencies": {
    "azle": "^0.20.1"
  },
  "devDependencies": {
    "ts-node": "^10.9.1",
    "typescript": "^5.2.2"
  }
}

Building the canister is straight forward using the Azle CLI tool in the root dir of the project:

npx azle backend

This should render an output like this:

Building canister backend

Done in 29.40s

🎉 Built canister backend at .azle/backend/backend.wasm

Before deploying the backend canister, let's have a look at the code! Every canister has a service interface that defines the methods that can be called on the canister. The service interface is defined in a file called backend.did:

service : (siwe_provider_canister : text) -> {
  "get_my_profile" : () -> (GetMyProfileResponse) query;
  "save_my_profile" : (Name, AvatarUrl) -> (SaveMyProfileResponse);
  "list_profiles" : () -> (ListProfilesResponse) query;
};

Here, we define three methods: get_my_profile, save_my_profile, and list_profiles. The get_my_profile and list_profiles methods are marked as query, meaning they cannot change the state of the canister. The save_my_profile method is not marked as query, meaning it can change the state of the canister.

`index.ts`

This is the entry point of the backend canister. It is the file that will be called when the canister is initialized.

import { Canister, Principal, init } from "azle";
import {
  SiweProviderCanister,
  initializeSiweProviderCanister,
} from "./siwe_provider";

import { get_my_profile } from "./service/get_my_profile";
import { list_profiles } from "./service/list_profiles";
import { save_my_profile } from "./service/save_my_profile";

export default Canister({
  init: init([Principal], (siweProviderPrincipal) => {
    initializeSiweProviderCanister(SiweProviderCanister(siweProviderPrincipal));
  }),

  get_my_profile,
  save_my_profile,
  list_profiles,
});

Okay, what happens here?

We begin by importing a Canister and a Principal from the azle package. azle provides us with all the objects and types we need to interact with ICP, conveniently exported at the top level.

Exporting a Canister object is the entry point of the canister. In addition to the three methods defined in the service interface, the backend canister also has an init method that is called when the canister is initialized. The init method takes the principal of the ic_siwe_provider canister as an argument and saves this information for later use.

`user_profiles.ts`

We need a suitable data structure to store the user profiles. In this file, we define a UserProfile type and a profileStore. The profileStore is a StableBTreeMap that maps user addresses to user profiles. The name StableBTreeMap gives a hint that this is a special kind of map. It has access to what is called stable memory, one of the most powerful features of ICP.

import { Record, StableBTreeMap, text } from "azle";

const UserKey = text;

type UserKey = typeof UserKey.tsType;

export const UserProfile = Record({
  address: text,
  name: text,
  avatar_url: text,
});

export type UserProfile = typeof UserProfile.tsType;

export let profileStore = StableBTreeMap<UserKey, UserProfile>(0);

Stable memory is a feature unique to ICP that provides a long-term, persistent data storage option separate from a canister's heap memory. When a canister is stopped or upgraded, the data stored in stable memory is not cleared or removed. The stable memory is preserved throughout the process while any other WebAssembly state is discarded. The maximum storage limit for the stable memory of one canister is 400GB!

Note, that is GB with a G, not an M or a K!

In addition to creating the UserProfile object, we also define the UserProfile type. azle provides us with a utility attribute tsType that we can use to extract the TypeScript type. Thanks for that!

`save_my_profile.ts`

Let's also take a closer look at one of the methods defined in the service interface: save_my_profile.

save_my_profile is defined as an async method that accepts two arguments: name and avatar_url. In addition to saving those two values to the profile, we also want to save the Ethereum address of the user.

import { UserProfile, profileStore } from "../user_profiles";
import { Variant, ic, text, update } from "azle";

import { SIWE_PROVIDER_CANISTER } from "../siwe_provider";

const SaveMyProfileResponse = Variant({
  Ok: UserProfile,
  Err: text,
});

export type SaveMyProfileResponse = typeof SaveMyProfileResponse.tsType;

async function get_address() {
  //...
  const response = await ic.call(SIWE_PROVIDER_CANISTER.get_address, {
    args: [ic.caller().toUint8Array()],
  });
  if (response.Err) throw new Error(response.Err);
  if (!response.Ok) throw new Error("Failed to get the caller address");
  return response.Ok;
}

export const save_my_profile = update(
  [text, text],
  SaveMyProfileResponse,
  async (name, avatar_url): Promise<SaveMyProfileResponse> => {
    try {
      const address = await get_address();
      const profile: UserProfile = {
        address: address.toString(),
        name,
        avatar_url,
      };
      profileStore.insert(ic.caller().toString(), profile);
      return { Ok: profile };
    } catch (error) {
      if (error instanceof Error) return { Err: error.message };
      return { Err: "Failed to save profile" };
    }
  }
);

The backend canister has initially no knowledge of the Ethereum address of the user. All it sees is an incoming call from an authenticated IC user. To get the Ethereum address, we need to call the get_address method on the ic_siwe_provider canister. That is called a cross canister call, and it is done using the ic.call method.

Note here, the argument we are passing along to the ic.call method. We are passing ic.caller().toUint8Array(), that returns the principal of the caller. If the principal - that is, the user identity - was generated by the ic_siwe_provider canister, the get_address method will return the Ethereum address of that user.

Build and deploy the backend canister

We are now ready to deploy the backend canister. The deploy details are defined in the Makefile:

deploy-backend:
    npm install
    dfx deploy backend --argument "(principal \"$$(dfx canister id ic_siwe_provider)\")"

Note here that we are passing the principal of the ic_siwe_provider canister as an argument to the backend canister. This is the principal that we saved in the init method of the backend canister.

To deploy the backend canister, run the following command:

make deploy-backend

That's it!

With all three canisters deployed, the application is now up and running! Users can connect their Ethereum wallet and create user profiles. The profiles are stored in the backend canister and displayed in the frontend application.

Access the application by opening the frontend canister in your browser. You can find the URL in the output of the dfx deploy frontend command.

To learn more about how to publish Azle TypeScript canisters to ICP, check out the Azle documentation. For more informtion about the features and inner workings of ICP, check out the extensive Internet Computer documentation.

Conclusion

In this article, we have looked at how to build a cross chain application on ICP using TypeScript and Sign in with Ethereum (SIWE) for authentication. We have seen how to use Azle to write TypeScript canisters and how to use stable memory as a way to store data that survives canister upgrades.

ICP offers a unique and powerful platform for building decentralized applications. In addition to the features we have looked at in this article, ICP also has a number of additional strengths:

True onchain randomness
Can handle secrets in a secure way even in a decentralized environment
Canisters can perform HTTPS outbound requests, effectively making them decentralised oracles
Canisters can hold BTC natively
Canisters can hold ETH natively
Plus much more!

I hope this article has given you a good understanding of how to get started building cross chain applications on ICP. If you have any questions or comments, please post them in the comments!

💜 Happy coding!

Publish an Astro website on the Internet Computer (ICP)

Kristofer — Thu, 15 Feb 2024 09:49:14 +0000

A step-by-step guide to deploying a static website to ICP and hosting it on a custom domain.

The Internet Computer (ICP) is a blockchain-based network that can host programs and data in the form of smart contracts, perform computations on smart contracts in a secure and trustworthy way, and scale infinitely. Not only can the ICP host smart contracts, but it can also host web pages. This means that you can open canister smart contracts directly in your browser just like regular websites.

In this article, we will go through the process of deploying a static website to the ICP. We will build the website using Astro and publish it using the dfx command-line tool that comes with the IC SDK.

Install Astro with the Automatic CLI

Astro is just great for building content-driven websites like blogs, marketing, and e-commerce. It is super fast, has great support for MDX, TailwindCSS, and more.

To get started, use the Astro CLI. The CLI will guide you through the process of setting up a new project and installing the necessary dependencies.

npm create astro@latest

You will be prompted to answer a few questions about your project. Choose the blog template. Once you have answered the questions, the CLI will create a new project and install the necessary dependencies.

If you are new to Astro, please see the full Astro installation instructions before proceeding. If you rather prefer copying the code for this project, you can find it on GitHub.

Make sure the project works

Before proceeding, take your new Astro project for a spin and ensure that it works as expected. Navigate to the project directory and start the development server:

npm run dev

Install the IC SDK

Once you have a working Astro project, you can install the IC SDK:

sh -ci "$(curl -fsSL https://internetcomputer.org/install.sh)"

The IC SDK is a software development kit used for creating and managing canister smart contracts on the ICP blockchain. The IC SDK supports Motoko and Rust programming languages by default, but developers can use other languages as well. In addition to building custom canister smart contracts, the IC SDK also supports deploying static website assets, which is what we will be doing in this article.

The IC SDK includes dfx, the command-line interface for the SDK. dfx is used to create, build, deploy, and manage canister smart contracts. dfx also includes a local replica of the ICP blockchain, which can be used for testing and development.

If you are using a machine running Apple silicon, you will need to have Rosetta installed. You can install Rosetta by running softwareupdate --install-rosetta in your terminal.

Create a dfx.json file

The dfx.json file is the main configuration file for ICP projects. It contains key settings that are required to build, deploy, and manage ICP applications.

Create a new file called dfx.json in the root of your project. Add the following content to the file:

{
  "canisters": {
    "blog": {
      "source": ["dist"],
      "type": "assets",
      "build": ["npm run build"]
    }
  }
}

Let's break down the settings in the dfx.json file:

canisters: This is an object that contains the configuration for each canister smart contract in the project. In this case, there is only one canister called blog.
source: This is an array of directories that contain the source code for the canister. In this case, the dist directory contains the compiled Astro website.
type: This is the type of canister. In this case, the canister is of type assets, which means it will host static assets like HTML, CSS, and JavaScript files.
build: This is an array of commands that will be run to build the canister. In this case, the npm run build command will be run to build the Astro website.

Start the local replica

Adding one configuration file to your Astro project, that's it! This is the only configuration you need to deploy a static website to the ICP. To try it out, now start the local replica of the ICP blockchain.

In a separate terminal, run the following command:

dfx start

Deploy the canister

Now that the local replica is running, you can deploy the canister to the ICP. Run the following command to deploy the canister:

dfx deploy

The dfx deploy command will build the canister using the npm run build command, and then deploy the canister to the local replica. Once the deployment is complete, you will see a message with the canister ID and the URL where the canister is hosted.

You should see the first page of your website loading without any issues.

Please note that clicking on any links will not work as the local replica does not support routing. During development, you can test the website by running npm run dev.

Deploy to the IC

Deploying to the local replica is great for testing and development, but to make the website accessible to the public, you need to deploy it to the ICP mainnet.

Deploying to mainnet uses the same dfx deploy command, but now with the --network flag set to ic.

dfx deploy --network ic

If you try this now, you will get an error message. You need to have a IC developer account and acquire "cycles" before you can deploy to the ICP mainnet.

1. Create a developer account

On ICP developers accounts, or identities, use a private/public key pair for authentication. Accounts are identified by a principal which is a generic identifier value that is used for users, canisters, and potentially other future concepts. Each developer account's principal value is derived from the account's public key from the private/public key pair.

To setup a developer account, follow these steps: Creating a developer account

2. Aquire cycles

ICP operates on a global network of nodes maintained by independent providers, who are compensated monthly in ICP tokens for their expenses like hardware and electricity. Canister smart contracts on the protocol pay for their resource usage (like storage and compute) in cycles, not in ICP tokens. These cycles, typically provided by the canister's developer, deplete with use and can be replenished by converting and burning ICP tokens.

You can get cycles for free for testing and development purposes!
Getting started with free cycles

3. Deploy!

Once setup with a developer account and cycles, you can now deploy the website to the ICP mainnet.

dfx deploy --network ic

The dfx deploy command will build the canister using the npm run build command, and then deploy the canister to the ICP mainnet. Once the deployment is complete, you will see a message with the canister ID and the URL where the canister is hosted.

The address where this website is hosted is:
https://avwrm-5iaaa-aaaal-qdhcq-cai.icp0.io

Configure DNS

Being able to access the website using the canister ID is great for testing and development, but it is not very user-friendly. To make the website more accessible to the public, wouldn't it be great if we could use a custom domain name instead?

Luckily, ICP supports custom domain names for canisters. You can either register the domain with the boundary nodes routing traffic to the canister, or you can host the domain on your own infrastructure. I chose the former (easier) option and configured the domain kristoferlund.se to point to the boundry nodes.

Configuring the domain name involves creating three DNS records: an A record, a TXT record, and a CNAME record. The exact steps for configuring DNS are layed out in the ICP documentation: Using custom domains.

The DNS setup involves creating a .ic-assets.json configuration file. For an Astro website, this file needs to be placed in the public directory.

Done!

That's it! You have successfully deployed an Astro website to the ICP. The website is now accessible to the public using a custom domain name.

Forem: Kristofer

Build Multi Chain Applications with IC-Alloy and the Internet Computer

Introduction

What Does It Mean to Hold Assets on a Blockchain?

Introducing IC-Alloy

1. An ICP Transport Layer

2. An ICP Signer

3. An ICP Provider

Show Me Some Code Already

Add IC-Alloy to Your Project

Read and Parse the IERC20 Source Code

The get_balance function

1. Parse address

2. Create an RPC service

3. Create a config object

4. Create a provider

5. Creating an instance of the IERC20 contract

6. Get the balance

Building Chain Fusion Applications

What the Schnorr?! Threshold Signatures on the Internet Computer

Threshold Signatures: A Primer

Unique Public Keys for Canister Identity and Security

Threshold ECDSA

Threshold Schnorr

Putting Threshold Signatures to Work

Conclusion

Introducing: Composite Attestations Engine (CATTS)

TL;DR

Table of contents

Introduction

Planned features

Future features

Flow

Recipe

Queries

Query variables

Query settings

Processor

Output schema

Composite Attestation

Receipt

Example run: User has attestation 1 AND attestation 2

Recipe

Query

Query variables

Query settings

Processor

Output schema

Run

1. Run queries

2. Run processor

3. Create attestations

4. Create run receipt

Telegram - CATTS Community

Create a cross chain ETH/ICP application using Azle and TypeScript

A TypeScript smart contract with a React/Vite frontend using Sign in with Ethereum (SIWE) for authentication.

ICP runs full-stack applications on the blockchain

Use Azle to write TypeScript canisters

Sign in with Ethereum (SIWE) for cross-chain authentication

Let's build!

Install the IC SDK

Clone the example repository

dfx.json configures the project canisters

Configure and deploy the ic_siwe_provider canister

The frontend application

main.tsx:

ic/Actors.tsx

components/profile/EditProfile.tsx

Build and deploy the frontend canister

The backend

index.ts

user_profiles.ts

save_my_profile.ts

Build and deploy the backend canister

That's it!

Conclusion

💜 Happy coding!

Publish an Astro website on the Internet Computer (ICP)

Install Astro with the Automatic CLI

Make sure the project works

The `get_balance` function

`dfx.json` configures the project canisters

Configure and deploy the `ic_siwe_provider` canister

`main.tsx`:

`ic/Actors.tsx`

`components/profile/EditProfile.tsx`

`index.ts`

`user_profiles.ts`

`save_my_profile.ts`