Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ Geth (or [go-ethereum](https://github.com/ethereum/go-ethereum)) is the official

## Coreth

[Coreth](https://github.com/ava-labs/coreth) is a fork of Geth maintained by Ava Labs. It implements the EVM for the C-Chain and has been adapted to work with Avalanche Consensus.
[Coreth](https://github.com/ava-labs/avalanchego/tree/master/graft/coreth) is a fork of Geth maintained by Ava Labs. It implements the EVM for the C-Chain and has been adapted to work with Avalanche Consensus.

## Subnet-EVM

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -19,15 +19,15 @@ cast keccak "SendWarpMessage(address,bytes32,bytes)"

To find a specific warp messageID, one must know the block number or block hash to retrieve the logs, or be monitoring all events, looking for and indexing messages.

When a block is [accepted](https://github.com/ava-labs/coreth/blob/7242ae2d235593d2bb14e2496b6ed102aab14c3d/precompile/contracts/warp/config.go#L130) by the network, a precompile hook is called, and the EVM saves the warp message to a local database. The validator node will then be willing to sign any messages in that database upon request, typically via an `AppRequest` message over the p2p network.
When a block is [accepted](https://github.com/ava-labs/avalanchego/blob/master/graft/coreth/precompile/contracts/warp/config.go#L133) by the network, a precompile hook is called, and the EVM saves the warp message to a local database. The validator node will then be willing to sign any messages in that database upon request, typically via an `AppRequest` message over the p2p network.

### Receiving Warp Messages

On the EVM, any smart contract can call the precompile

which returns the warp message and verifies the attached signature. But what is `index`? Where does it get the warp message from? The answer is, you! When you send a tx to any contract that eventually calls `getVerifiedWarpMessage`, you **must** pass in the signed warp message as a “predicate”. It’s called an AccessList, and typically this is an optional field that can be used by the EVM to pre-fetch storage slots that will be accessed, for efficiency and reducing gas costs. But Warp cleverly (ab)uses this feature of the EVM to verify the signature of the warp message, and then make the warp message available during the transactions lifetime, by calling `getVerifiedWarpMessage`. You can pass multiple warp messages which is where the `index` comes in. (All of this is abstracted away by Teleporter for EVM to EVM comms)

Details: [Warp README](https://github.com/ava-labs/coreth/blob/7242ae2d235593d2bb14e2496b6ed102aab14c3d/precompile/contracts/warp/README.md)
Details: [Warp README](https://github.com/ava-labs/avalanchego/blob/master/graft/coreth/precompile/contracts/warp/README.md)

### Teleporter

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -50,15 +50,15 @@ cast keccak "SendWarpMessage(address,bytes32,bytes)"

To find a specific warp messageID, one must know the block number or block hash to retrieve the logs, or be monitoring all events, looking for and indexing messages.

When a block is [accepted](https://github.com/ava-labs/coreth/blob/7242ae2d235593d2bb14e2496b6ed102aab14c3d/precompile/contracts/warp/config.go#L130) by the network, a precompile hook is called, and the EVM saves the warp message to a local database. The validator node will then be willing to sign any messages in that database upon request, typically via an `AppRequest` message over the p2p network.
When a block is [accepted](https://github.com/ava-labs/avalanchego/blob/master/graft/coreth/precompile/contracts/warp/config.go#L133) by the network, a precompile hook is called, and the EVM saves the warp message to a local database. The validator node will then be willing to sign any messages in that database upon request, typically via an `AppRequest` message over the p2p network.

### Receiving Warp Messages

On the EVM, any smart contract can call the precompile

which returns the warp message and verifies the attached signature. But what is `index`? Where does it get the warp message from? The answer is, you! When you send a tx to any contract that eventually calls `getVerifiedWarpMessage`, you **must** pass in the signed warp message as a “predicate”. It’s called an AccessList, and typically this is an optional field that can be used by the EVM to pre-fetch storage slots that will be accessed, for efficiency and reducing gas costs. But Warp cleverly (ab)uses this feature of the EVM to verify the signature of the warp message, and then make the warp message available during the transactions lifetime, by calling `getVerifiedWarpMessage`. You can pass multiple warp messages which is where the `index` comes in. (All of this is abstracted away by ICM for EVM to EVM comms)

Details: [Warp README](https://github.com/ava-labs/coreth/blob/7242ae2d235593d2bb14e2496b6ed102aab14c3d/precompile/contracts/warp/README.md)
Details: [Warp README](https://github.com/ava-labs/avalanchego/blob/master/graft/coreth/precompile/contracts/warp/README.md)

### Interchain Messaging Contracts (ICM)

Expand Down
2 changes: 2 additions & 0 deletions content/blog/cortina-x-chain-linearization.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,8 @@ Cortina modifies how these delegation fees are distributed for all validators th

## Increased C-Chain Gas Limit

Warning: The original coreth repoistory has been deprecated and it's code has been moved into [avalanche go](https://github.com/ava-labs/avalanchego/tree/master/graft/coreth) and Apricot does no longer apply

Since Apricot Phase 1, the C-Chain block gas limit has been [set to 8M gas](https://github.com/ava-labs/coreth/blob/b1223203dbca7708142b8884f46a4deec678d80e/params/avalanche_params.go#L21). Blocks on the C-Chain are produced every ~2s, so this setting limits the max amount of gas that can be consumed every 10s to ~40M gas. The gas target for every rolling 10s window, however, is set to [15M gas](https://github.com/ava-labs/coreth/blob/b1223203dbca7708142b8884f46a4deec678d80e/params/avalanche_params.go#L32). This means that when more than 15M gas is used in a 10s window, the gas price will go up (and go down when less than 15M is used). You can read more about how dynamic fees work on the C-Chain [here](https://medium.com/avalancheavax/apricot-phase-three-c-chain-dynamic-fees-432d32d67b60).

Outside of limiting the amount of gas that can be consumed in some window at any gas price, the block gas limit also limits the complexity of transactions that can be issued in a single block. As different developers on Avalanche began to deploy more complex dApps, they've expressed that 8M gas per block isn't enough for their use case. Cortina increases the C-Chain block gas limit to 15M gas. To avoid increasing the amount of resources required to validate the Primary Network, the gas target will remain unchanged at 15M gas per 10s.
Expand Down
2 changes: 1 addition & 1 deletion content/blog/granite-upgrade.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -140,7 +140,7 @@ Two new headers have been introduced as part of ACP-226 for dynamic block time m
1. **`timestampMilliseconds`** (uint64) - Timestamp in milliseconds for more precise block timing
2. **`minDelayExcess`** (uint64) - Tracks the excess delay for dynamic block time adjustments

See the [full changelog](https://github.com/ava-labs/coreth/blob/master/RELEASES.md#pending-release) for implementation details.
See the [full changelog](https://github.com/ava-labs/avalanchego/blob/master/graft/coreth/RELEASES.md#pending-release) for implementation details.

#### For L1s

Expand Down
2 changes: 1 addition & 1 deletion content/docs/avalanche-l1s/custom-precompiles/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -80,7 +80,7 @@ When a precompile is called, the EVM checks if the input address is a precompile

### Stateful Precompiled Contracts

A stateful precompile builds on a precompile in that it adds state access. Stateful precompiles are not available in the default EVM, and are specific to Avalanche EVMs such as [Coreth](https://github.com/ava-labs/coreth) and [Subnet-EVM](https://github.com/ava-labs/subnet-evm).
A stateful precompile builds on a precompile in that it adds state access. Stateful precompiles are not available in the default EVM, and are specific to Avalanche EVMs such as [Coreth](https://github.com/ava-labs/avalanchego/tree/master/graft/coreth) and [Subnet-EVM](https://github.com/ava-labs/subnet-evm).

A stateful precompile follows this [interface](https://github.com/ava-labs/subnet-evm/blob/helloworld-official-tutorial-v2/precompile/contract/interfaces.go#L17-L20):

Expand Down
38 changes: 38 additions & 0 deletions content/docs/dapps/index.mdx
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
---
title: Introduction
description: Learn about the Avalanche C-Chain.
---

Avalanche is a [network of networks](/docs/quick-start/primary-network). One of the chains running on Avalanche Primary Network is an EVM fork called the C-Chain (contract chain).

C-Chain runs a fork of [`go-ethereum`](https://geth.ethereum.org/docs/rpc/server) called [`coreth`](https://github.com/ava-labs/avalanchego/tree/master/graft/coreth) that has the networking and consensus portions replaced with Avalanche equivalents. What's left is the Ethereum VM, which runs Solidity smart contracts and manages data structures and blocks on the chain.

As a result, you get a blockchain that can run all the Solidity smart contracts from Ethereum, but with much greater transaction bandwidth and instant finality that [Avalanche's revolutionary consensus](/docs/quick-start/avalanche-consensus) enables.

Coreth is loaded as a plugin into [AvalancheGo](https://github.com/ava-labs/avalanchego), the client node application used to run Avalanche network. Any dApp deployed to Avalanche C-Chain will function the same as on Ethereum, but much faster and cheaper.

## Add C-Chain to Wallet

### Avalanche C-Chain Mainnet

- **Network Name**: Avalanche Mainnet C-Chain
- **RPC URL**: https://api.avax.network/ext/bc/C/rpc
- **WebSocket URL**: wss://api.avax.network/ext/bc/C/ws
- **ChainID**: `43114`
- **Symbol**: `AVAX`
- **Explorer**: https://subnets.avax.network/c-chain

### Avalanche Fuji Testnet

- **Network Name**: Avalanche Fuji C-Chain
- **RPC URL**: https://api.avax-test.network/ext/bc/C/rpc
- **WebSocket URL**: wss://api.avax-test.network/ext/bc/C/ws
- **ChainID**: `43113`
- **Symbol**: `AVAX`
- **Explorer**: https://subnets-test.avax.network/c-chain

### Via Block Explorers

Head to either explorer linked above and select "Add Avalanche C-Chain to Wallet" under "Chain Info" to automatically add the network.

Alternatively, visit [chainlist.org](https://chainlist.org/?search=Avalanche&testnets=true) and connect your wallet.
173 changes: 173 additions & 0 deletions content/docs/dapps/smart-contract-dev/interact-golang-app.mdx
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please do not recommit removed content

Original file line number Diff line number Diff line change
@@ -0,0 +1,173 @@
---
title: Interact from Golang App
description: Interact with a smart contract from your Golang-based application.
---

`abigen` is a tool provided by the Go Ethereum (Geth) client that generates Go bindings for Solidity smart contracts. Developers would need to use Abigen when they want to interact with a smart contract written in Solidity from a Go programming language application. It enables developers to easily call functions and access data from Solidity contracts in a Go application. This tutorial demonstrates how to compile a solidity contract into Golang to deploy and call contracts programmatically.

## How to Build

Download the solidity compiler from [solc-bin](https://github.com/ethereum/solc-bin).

Copy the appropriate compiler into your current path. ~/bin/ is a common path in most Linux distributions.

```bash
cp linux-amd64/solc-linux-amd64-v0.8.9+commit.e5eed63a ~/bin
```

Ensure solc is properly installed by checking its version.

```bash
solc --version
```

Clone AvalancheGo and Build Abigen.

```bash
git clone [email protected]:ava-labs/avalanchego.git
cd avalanchego/graft/coreth
go build -o abigen cmd/abigen/*.go
cp abigen ~/bin
```

Compile a contract.

```bash
abigen --sol counter.sol --pkg main --out counter.go
```

This will produce `counter.go` suitable to interact with contract.

## Example Code

Setup the connection to `avalanchego`, then deploy, call, and fetch values from the contract.

Abigen offers more features for complicated contracts, the following is provided as an example to get started using the basic contract

```solidity
package main

import (
"context"
"log"
"math/big"
"strings"
"time"

"github.com/ava-labs/avalanchego/utils/constants"
"github.com/ava-labs/avalanchego/utils/formatting"
"github.com/ava-labs/avalanchego/graft/coreth/accounts/abi/bind"
"github.com/ava-labs/avalanchego/graft/coreth/core/types"
"github.com/ava-labs/avalanchego/graft/coreth/ethclient"
"github.com/ava-labs/avalanchego/graft/coreth/params"
"github.com/ava-labs/avalanchego/graft/coreth/rpc"
"github.com/decred/dcrd/dcrec/secp256k1/v3"
"github.com/ethereum/go-ethereum/common"
"github.com/ethereum/go-ethereum/crypto"
)

func main() {
// setup client
rc, err := rpc.Dial("http://localhost:9650/ext/bc/C/rpc")
if err != nil {
log.Fatal(err)
}
ec := ethclient.NewClient(rc)

ctx := context.Background()

// fetch networkid
networkId, err := ec.ChainID(ctx)
if err != nil {
log.Fatal(err)
}

// parse key
privateKeyString := "PrivateKey-ewoqjP7PxY4yr3iLTpLisriqt94hdyDFNgchSxGGztUrTXtNN"
privateKeyBytes, err := formatting.Decode(formatting.CB58, strings.TrimPrefix(privateKeyString, constants.SecretKeyPrefix))
if err != nil {
log.Fatal(err)
}
privateKey := secp256k1.PrivKeyFromBytes(privateKeyBytes)
privateKeyECDSA := privateKey.ToECDSA()

// derive 'c' address
cAddress := crypto.PubkeyToAddress(privateKeyECDSA.PublicKey)

// setup signer and transaction options.
signer := types.LatestSignerForChainID(networkId)
to := &bind.TransactOpts{
Signer: func(address common.Address, transaction *types.Transaction) (*types.Transaction, error) {
return types.SignTx(transaction, signer, privateKeyECDSA)
},
From: cAddress,
Context: ctx,
GasLimit: params.ApricotPhase1GasLimit,
}

// deploy the contract
storageAddress, storageTransaction, storageContract, err := DeployStorage(to, ec)
if err != nil {
log.Fatal(err)
}

// wait for the transaction to be accepted
for {
r, err := ec.TransactionReceipt(ctx, storageTransaction.Hash())
if err != nil {
if err.Error() != "not found" {
log.Fatal(err)
}
time.Sleep(1 * time.Second)
continue
}
if r.Status != 0 {
break
}
time.Sleep(1 * time.Second)
}

log.Println("storageAddress", storageAddress)
log.Println("storageTransaction", storageTransaction)

// Call store on the contract
storeTransaction, err := storageContract.Store(to, big.NewInt(1), common.BytesToAddress([]byte("addr1")))
if err != nil {
log.Fatal(err)
}

// wait for the transaction
for {
r, err := ec.TransactionReceipt(ctx, storeTransaction.Hash())
if err != nil {
if err.Error() != "not found" {
log.Fatal(err)
}
time.Sleep(1 * time.Second)
continue
}
if r.Status != 0 {
break
}
time.Sleep(1 * time.Second)
}

log.Println("storeTransaction", storeTransaction)

// setup call options for storage
co := &bind.CallOpts{
Accepted: true,
Context: ctx,
From: storageAddress,
}

// retrieve the value of the contract
storageValue, err := storageContract.Retrieve(co)
if err != nil {
log.Fatal(err)
}

log.Println("storageValue", storageValue)
}
```

4 changes: 2 additions & 2 deletions content/docs/primary-network/exchange-integration.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -145,10 +145,10 @@ thrown indicating that unfinalized data cannot be queried (as of

If you plan on extracting data from the C-Chain into your own systems using
Golang, we recommend using our custom
[`ethclient`](https://github.com/ava-labs/coreth/tree/master/ethclient). The
[`ethclient`](https://github.com/ava-labs/avalanchego/tree/master/graft/coreth/ethclient). The
standard `go-ethereum` Ethereum client does not compute block hashes correctly
(when you call `block.Hash()`) because it doesn't take into account the added
[ExtDataHash](https://github.com/ava-labs/coreth/blob/2c3cfac5f766ce5f32a2eddc43451bdb473b84f1/core/types/block.go#L98)
[ExtDataHash](https://github.com/ava-labs/avalanchego/blob/master/graft/coreth/core/types/block.go#L98)
header field in Avalanche C-Chain blocks, which is used move AVAX between chains
(X-Chain and P-Chain). You can read more about our multi-chain abstraction
[here](/docs/primary-network) (out of scope for a
Expand Down
2 changes: 1 addition & 1 deletion content/docs/primary-network/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -75,7 +75,7 @@ A node can become a validator for the Primary Network by staking at least **2,00

The **C-Chain** is an implementation of the Ethereum Virtual Machine (EVM). The [C-Chain's API](/docs/rpcs/c-chain) supports Geth's API and supports the deployment and execution of smart contracts written in Solidity.

The C-Chain is an instance of the [Coreth](https://github.com/ava-labs/coreth) Virtual Machine.
The C-Chain is an instance of the [Coreth](https://github.com/ava-labs/avalanchego/tree/master/graft/coreth) Virtual Machine.

| Property | Mainnet | Fuji Testnet |
|----------|---------|--------------|
Expand Down
2 changes: 1 addition & 1 deletion content/docs/primary-network/virtual-machines.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,7 @@ The choice depends on your needs. Subnet-EVM provides a quick start with Ethereu
description="A decentralized timestamp blockchain written in Golang (recommended for beginners)"
/>
<Card
href="https://github.com/ava-labs/coreth"
href="https://github.com/ava-labs/avalanchego/tree/master/graft/coreth"
title="Coreth"
description="An implementation of EVM that powers the Avalanche C-Chain and supports Solidity smart contracts"
/>
Expand Down
44 changes: 44 additions & 0 deletions content/docs/quick-start/primary-network.mdx
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, this file was moved to docs/primary-network as index file

Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
---
title: Primary Network
description: Learn about the Avalanche Primary Network and its three blockchains.
---

Avalanche is a heterogeneous network of blockchains. As opposed to homogeneous networks, where all applications reside in the same chain, heterogeneous networks allow separate chains to be created for different applications.

The Primary Network is a special [Avalanche L1](/docs/quick-start/avalanche-l1s) that runs three blockchains:

- The Platform Chain [(P-Chain)](/docs/quick-start/primary-network#p-chain)
- The Contract Chain [(C-Chain)](/docs/quick-start/primary-network#c-chain)
- The Exchange Chain [(X-Chain)](/docs/quick-start/primary-network#x-chain)

<Callout title="Note">
[Avalanche Mainnet](/docs/quick-start/networks/mainnet) is comprised of the Primary Network and all deployed Avalanche L1s.
</Callout>

A node can become a validator for the Primary Network by staking at least **2,000 AVAX**.

![Primary network](/images/primary-network1.png)

## The Chains

All validators of the Primary Network are required to validate and secure the following:

### C-Chain

The **C-Chain** is an implementation of the Ethereum Virtual Machine (EVM). The [C-Chain's API](/docs/api-reference/c-chain/api) supports Geth's API and supports the deployment and execution of smart contracts written in Solidity.

The C-Chain is an instance of the [Coreth](https://github.com/ava-labs/avalanchego/tree/master/graft/coreth) Virtual Machine.

### P-Chain

The **P-Chain** is responsible for all validator and Avalanche L1-level operations. The [P-Chain API](/docs/api-reference/p-chain/api) supports the creation of new blockchains and Avalanche L1s, the addition of validators to Avalanche L1s, staking operations, and other platform-level operations.

The P-Chain is an instance of the Platform Virtual Machine.

### X-Chain

The **X-Chain** is responsible for operations on digital smart assets known as **Avalanche Native Tokens**. A smart asset is a representation of a real-world resource (for example, equity, or a bond) with sets of rules that govern its behavior, like "can't be traded until tomorrow." The [X-Chain API](/docs/api-reference/x-chain/api) supports the creation and trade of Avalanche Native Tokens.

One asset traded on the X-Chain is AVAX. When you issue a transaction to a blockchain on Avalanche, you pay a fee denominated in AVAX.

The X-Chain is an instance of the Avalanche Virtual Machine (AVM).
2 changes: 1 addition & 1 deletion content/docs/rpcs/c-chain/api.mdx
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: "C-Chain API"
description: "This page is an overview of the C-Chain API associated with AvalancheGo."
edit_url: https://github.com/ava-labs/coreth/edit/master/plugin/evm/api.md
edit_url: https://github.com/ava-labs/avalanchego/edit/master/graft/coreth/plugin/evm/api.md
---

<Callout title="Note">
Expand Down
Loading