You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Metadata SEO (titles + descriptions) (celo-org#223)
* Celo Basics section metadata
Added Celo Basics section metadata (title + descriptions)
* Title and Description for Celo Basics
Finished Metadata (title + description) for Celo Basics section
* Title and Description for Wallets Section
Added Metadata (title + description) to wallets section.
* Why Celo and Welcome updates
Changed description for Why Celo/Welcome pages
* Remaining Welcome Pages
Updated metadata for remaining welcome pages. (Excluding Protocol section - completing next)
* Consensus metadata
Added metadata to consensus section along with some formatting and header updates
* Metadata up to validator rewards
Updated metadata up to validator rewards
* Metadata > transactions section
Added description and titles through 'transaction' section
* Finished "Welcome Section" Metadata
Finished Metadata for all of Welcome section
* Description updates
Small updates to descriptions.
* welcome page videos
Embedded welcome page videos
* Remove videos
Removed video embeds from welcome page
* Metadata Contributor section
Completed title + description for contributor section
* Integrations Metadata
Added titles and descriptions for Integrations section
* Metadata for Owners section
Updated titles and descriptions for Celo owners section.
* Validator Metadata
Updates to titles and descriptions in validator section
* Metadata developers
Updated developers section titles and descriptions
* Celo whitepapers
Update whitepapers description
* Move DApp Gallery + descriptions
Moved dapp gallery to top of get started. Small tweaks to description text.
* Edits
small edits
* Formatting updates
+ ____
+ What is Celo
+ YouTube Embeds
+ Links
* Join the community
Added join the community link to welcome page
* Updated links
Changed links on introduction to celo
* Update bridging-native-assets.md
* Update bridging-tokens-with-etherscan.md
* Update bridging-native-assets.md
* Update index.md
* Update full-node-incentives.md
* Update celo-recovery.md
* Update contributing.md
* Update hello-contract-remote-node.md
* Update hellocontracts.md
* Update using-js-keystores.md
* Update running-a-full-node-in-alfajores.md
* Update running-a-full-node-in-alfajores.md
* Update running-a-full-node-in-baklava.md
* Update mainnet-network-disclaimer.md
* Update celo-economic-model.md
Co-authored-by: Josh <[email protected]>
2. Open the **Write Contract** pane > **connect your wallet** > then select **sendToEVMLike**
27
+
* Open the **Write Contract** pane > **connect your wallet** > then select **sendToEVMLike**
28
28
* Optics is designed to support multiple non-EVM chains
29
29
* This function helps you send ETH to another chain that uses EVM-style addresses
30
30
31
31
32
32
33
-
1. For **payableAmount** enter the amount you'd like to send in ETH.
33
+
* For **payableAmount** enter the amount you'd like to send in ETH.
34
34
35
-
:::info
35
+
:::tip
36
36
37
37
1 wei = 1 / 10 ** 18 ETH.
38
38
39
39
:::
40
40
41
-
4. For **_domain**, enter the domain ID of the chain to which you'd like to send tokens.
42
-
43
-
:::info
41
+
* For **_domain**, enter the domain ID of the chain to which you'd like to send tokens.
44
42
45
43
Domain IDs are like phone numbers. They represent the chain you're going to call.
46
-
* 1667591279 for **Celo**
47
-
* 1886350457 for **Polygon**
48
-
* 6648936 for **Ethereum**
49
44
50
-
:::
45
+
<Tabs>
46
+
<TabItemvalue="Celo"label="On Celo"default>
47
+
Celo Domain ID = 1667591279
48
+
</TabItem>
49
+
<TabItemvalue="Polygon"label="On Polygon">
50
+
Polygon Domain ID = 1886350457
51
+
</TabItem>
52
+
<TabItem value="Ethereum" label="On Ethereum">
53
+
Ethereum Domain ID = 6648936
54
+
</TabItem>
55
+
</Tabs>
51
56
52
-
5. For **_to**, enter the address of the recipient on the destination chain.
57
+
* For **_to**, enter the address of the recipient on the destination chain.
58
+
* Select **write** > **sign the transaction** > then **send** it to the network.
53
59
54
-
6. Select **write** > **sign the transaction** > then **send** it to the network.
55
-
56
-
---
57
60
58
-
## Step 2: Wait
61
+
## Wait
59
62
60
63
Wait for a moment for your transaction to finalize on the network.
description: Bridging ERC-20 tokens from Ethereum and Polygon to Celo.
3
4
---
4
5
5
-
Bridging ERC-20 tokens from Ethereum and Polygon to Celo.
6
+
import Tabs from '@theme/Tabs';
7
+
import TabItem from '@theme/TabItem';
6
8
7
-
---
8
-
9
-
## How to complete this guide
9
+
# Bridge Tokens with Etherscan
10
10
11
-
***Step 1:** Approve the Bridge (for token usage)
12
-
***Step 2:** Call the Bridge (to send tokens)
13
-
***Step 3:** Wait
11
+
How to bridge ERC-20 tokens from Ethereum and Polygon to Celo.
14
12
15
-
---
13
+
___
16
14
17
-
## Step 1: Approve the Bridge
15
+
## Approve the Bridge
18
16
19
17
Start by approving token usage on the bridge.
20
18
21
-
1. Navigate to the [Etherscan](https://etherscan.io/) page for the token you want to send
22
-
2. Open the **Write Contract** pane > **connect your wallet** > and select **approve**
19
+
* Navigate to the [Etherscan](https://etherscan.io/)(or [Polygonscan](https://polygonscan.com/)) page for the token you want to send
20
+
* Open the **Write Contract** pane > **connect your wallet** > and select **approve**
23
21
24
22
25
23
26
-
3. For **spender** enter the BridgeRouter address:
2. Open the **Write as Proxy** pane > connect your wallet > and select send
68
+
* Open the **Write as Proxy** pane > connect your wallet > and select send
71
69
72
70
73
71
74
-
3. For **_token**, enter the address of the token you want to send
75
-
4. For **_amount**, enter the amount of tokens you'd like to send in that token's smallest unit.
72
+
* For **_token**, enter the address of the token you want to send
73
+
* For **_amount**, enter the amount of tokens you'd like to send in that token's smallest unit.
76
74
77
75
:::info
78
76
79
77
This should be the same number you approved earlier.
80
78
81
79
:::
82
80
83
-
5. For **_destination**, enter the domain ID of the chain to which you'd like to send tokens.
81
+
* For **_destination**, enter the domain ID of the chain to which you'd like to send tokens.
84
82
85
-
:::info
83
+
<Tabs>
84
+
<TabItemvalue="Celo"label="On Celo"default>
85
+
Celo Domain ID = 1667591279
86
+
</TabItem>
87
+
<TabItemvalue="Polygon"label="On Polygon">
88
+
Polygon Domain ID = 1886350457
89
+
</TabItem>
90
+
<TabItemvalue="Ethereum"label="On Ethereum">
91
+
Ethereum Domain ID = 6648936
92
+
</TabItem>
93
+
</Tabs>
94
+
95
+
:::tip
86
96
87
-
Domain IDs are like phone numbers. They represent the chain you're going to call:
88
-
* 1667591279 for **Celo**
89
-
* 1886350457 for **Polygon**
90
-
* 6648936 for **Ethereum**
97
+
Domain IDs are like phone numbers. They represent the chain you're going to call.
91
98
92
99
:::
93
100
94
-
6. For **_recipient**, enter the address of the recipient on the destination chain.
101
+
* For **_recipient**, enter the address of the recipient on the destination chain.
95
102
* To help support future chains with longer addresses, Optics uses 32-byte addresses.
96
103
* To convert an Ethereum, Celo, or Polygon address to bytes32 you can add 24 0s after the 0x prefix
97
104
@@ -105,10 +112,8 @@ Domain IDs are like phone numbers. They represent the chain you're going to call
105
112
106
113
:::
107
114
108
-
7. Select **write** > **sign the transaction** > then **send** it to the network.
109
-
110
-
---
115
+
* Select **write** > **sign the transaction** > then **send** it to the network.
111
116
112
-
## Step 3: Wait
117
+
## Wait
113
118
114
119
Wait for a moment for your transaction to finalize on the network.
description: Overview of Celo's consensus protocol and network validators.
3
4
slug: /celo-codebase/protocol/consensus
4
5
---
6
+
# Consensus
7
+
8
+
Overview of Celo's consensus protocol and network validators.
9
+
10
+
___
11
+
12
+
## Protocol
5
13
6
14
Celo’s consensus protocol is based on an implementation called Istanbul, or IBFT. IBFT was developed by AMIS and [proposed](https://github.com/ethereum/EIPs/issues/650) as an extension to [go-ethereum](https://github.com/ethereum/go-ethereum) but never merged. Variants of IBFT exist in both the [Quorum](https://github.com/jpmorganchase/quorum) and [Pantheon](https://github.com/PegaSysEng/pantheon) clients. We’ve modified Istanbul to bring it up to date with the latest [go-ethereum](https://github.com/ethereum/go-ethereum) releases and we’re fixing [correctness and liveness issues](https://arxiv.org/abs/1901.07160) and improving its scalability and security.
7
15
16
+
## Validators
17
+
8
18
Celo’s consensus protocol is performed by nodes that are selected as validators. There is a maximum cap on the number of active validators that can be changed by governance proposal, which is currently set at 100 validators. The active validator set is determined via the proof-of-stake process and is updated at the end of each epoch, a fixed period of approximately one day.
description: How Celo nodes join the network, establish a connection, and communiate their IP address.
3
4
---
4
5
5
-
All Celo nodes \(including our validators\) are using a variant of Ethereum's V4 discovery protocol to find other nodes within the network. Details of Ethereum's protocol can be found here: [https://github.com/ethereum/devp2p/blob/master/discv4.md](https://github.com/ethereum/devp2p/blob/master/discv4.md).
6
+
# Locating Nodes
6
7
7
-
When a node attempts to join the network, it will execute our discovery protocol. It will first send a request to the bootnodes to retrieve a list of other nodes of the network. The bootnodes will then reply with that list, and then the joining node will then send additional requests to nodes in that list to find additional nodes in the network. The main difference in Celo's discovery protocol compared to Ethereum's is that it will require that the joining node's networkID be the same as the bootnodes' \(and the same as all other network's nodes\). Also, all of the messages in Celo's discovery protocol must be hashed with a special salt to be accepted by other nodes. The reason why these changes were made is so that each node within a network will only store information of other nodes that have the same networkID (to distinguish nodes from other networks) and the same special salt \(to distinguish nodes from other blockchains, such as Ethereum\).
8
+
How Celo nodes join the network, establish a connection, and communiate their IP address.
9
+
10
+
___
11
+
12
+
## V4 Discovery Protocol
13
+
14
+
All Celo nodes \(including our validators\) are using a variant of Ethereum's V4 discovery protocol to find other nodes within the network. Details of Ethereum's protocol can be found [here](https://github.com/ethereum/devp2p/blob/master/discv4.md).
15
+
16
+
## Joining the Network
17
+
18
+
When a node attempts to join the network, it will execute Celo's discovery protocol.
19
+
20
+
It will first send a request to the bootnodes to retrieve a list of other nodes of the network. The bootnodes will then reply with that list, and then the joining node will then send additional requests to nodes in that list to find additional nodes in the network. The main difference in Celo's discovery protocol compared to Ethereum's is that it will require that the joining node's networkID be the same as the bootnodes' \(and the same as all other network's nodes\).
21
+
22
+
Also, all of the messages in Celo's discovery protocol must be hashed with a special salt to be accepted by other nodes. The reason why these changes were made is so that each node within a network will only store information of other nodes that have the same networkID (to distinguish nodes from other networks) and the same special salt \(to distinguish nodes from other blockchains, such as Ethereum\).
23
+
24
+
## Establishing a Connection
8
25
9
26
Once a joining node finds other nodes, it will establish direct TCP connections to a subset of them. This will allow that node to sync it's blockchain and transactions. Validators will additionally attempt to establish TCP connections to the rest of the validators, so that it can send consensus messages directly to them, instead of via gossip. The reason that the validators do this is to minimize the latency of messages that are sent and received among the validators, and to ultimately help minimize block time.
10
27
11
-
The way that validators communicate their IP address to other validators is by periodically gossiping a subprotocol message that we call an _IstanbulAnnounce_ message. That message will contain `n` copies (where `n` is the total number of validators for the current epoch) of the sending validator's IP address where each copy is encrypted with the other validators' public key. Once a validator receives a gossiped _IstanbulAnnounce_ message, it will decrypt the encrypted IP address that was encrypted with its public key, and then establish a TCP connection to it. All consensus related messages will then sent via those direct TCP connections. When an epoch ends, a validator will establish new connections with any newly elected validator and disconnect from any removed validators. If the validator itself is removed from the new epoch's validator set, then it will disconnect with all the validators.
28
+
## Communicating IP Address
29
+
30
+
The way that validators communicate their IP address to other validators is by periodically gossiping a subprotocol message that we call an _IstanbulAnnounce_ message.
31
+
32
+
That message will contain `n` copies (where `n` is the total number of validators for the current epoch) of the sending validator's IP address where each copy is encrypted with the other validators' public key. Once a validator receives a gossiped _IstanbulAnnounce_ message, it will decrypt the encrypted IP address that was encrypted with its public key, and then establish a TCP connection to it. All consensus related messages will then sent via those direct TCP connections.
33
+
34
+
When an epoch ends, a validator will establish new connections with any newly elected validator and disconnect from any removed validators. If the validator itself is removed from the new epoch's validator set, then it will disconnect with all the validators.
0 commit comments