Changeset View
Changeset View
Standalone View
Standalone View
_posts/2022-08-03-avalanche-development-update.md
| --- | --- | ||||
| layout: post | layout: post | ||||
| title: eCash Avalanche Development Update | title: eCash Avalanche Development Update | ||||
| subtitle: Robust Networking and Iterative Improvements | subtitle: Robust Networking and Iterative Improvements | ||||
| multiLangId: 2022-08-03-avalanche-dev-update | multiLangId: 2022-08-03-avalanche-dev-update | ||||
| lang: en | lang: en | ||||
| --- | --- | ||||
|  |  | ||||
| This article is to bring people up to date on what’s been achieved, and what's been | This article is to bring people up to date on what’s been achieved, and what's been | ||||
| happening in our development activities on Avalanche for eCash, since the | happening in our development activities on Avalanche for eCash, since the | ||||
| [previous update](/2022-05-02-avalanche-development-update/) from early May 2022. | [previous update](/2022-05-02-avalanche-development-update/) from early May 2022. | ||||
| The two primary advancements since the last update were: | The two primary advancements since the last update were: | ||||
| 1. Faster and more robust discovery of Proofs from the network. This was accomplished through | 1. Faster and more robust discovery of Proofs from the network. This was accomplished through the | ||||
| implementation of a “Compact Proof Request” networking capability which allow nodes to actively request | implementation of a “Compact Proof Request” networking capability which allows nodes to actively request | ||||
| all the Proofs that other node know about, and | all the Proofs that other nodes know about, and | ||||
| 2. Many cycles of iterative improvements via repeated rounds of testing. The details of these fixes and | 2. Many cycles of iterative improvements via repeated rounds of testing. The details of these fixes and | ||||
| improvements are expanded later in this article. | improvements are expanded later in this article. | ||||
| As context for understanding these developments, it may be helpful to explain how the networking requirements | As context for understanding these developments, it may be helpful to explain how the networking requirements | ||||
| for the avalanche protocol differ from traditional Nakamoto consensus. | for the Avalanche protocol differ from traditional Nakamoto consensus. | ||||
| ## Avalanche Networking | ## Avalanche Networking | ||||
| The Avalanche protocol and Nakamoto consensus are two different consensus protocols that | The Avalanche protocol and Nakamoto consensus are two different consensus protocols that | ||||
| have different properties and tradeoffs. One of the characteristics of the Avalanche protocol | have different properties and tradeoffs. One of the characteristics of the Avalanche protocol | ||||
| is that its security relies on the nodes being well connected to the rest of the network. | is that its security relies on the nodes being well connected to the rest of the network. | ||||
| This is quite different from Nakamoto consensus, which only needs enough connectivity to be | This is quite different from Nakamoto consensus, which only needs enough connectivity to be | ||||
| confident that it can get the longest Proof-of-Work chain. In other words, Nakamoto consensus | confident that it can get the longest Proof-of-Work chain. In other words, Nakamoto consensus | ||||
| ▲ Show 20 Lines • Show All 78 Lines • ▼ Show 20 Lines | |||||
| agree on a stable set. But the startup process presents us with a chicken-and-egg problem: | agree on a stable set. But the startup process presents us with a chicken-and-egg problem: | ||||
| We need a stable quorum to start using Avalanche, but we want to use Avalanche polling to | We need a stable quorum to start using Avalanche, but we want to use Avalanche polling to | ||||
| maintain the quorum. | maintain the quorum. | ||||
| A simple idea would be to simply hard-code a list of nodes to connect to to obtain the initial | A simple idea would be to simply hard-code a list of nodes to connect to to obtain the initial | ||||
| state. In fact, as far as we understand, this is actually what AVAX does for its bootstrap. | state. In fact, as far as we understand, this is actually what AVAX does for its bootstrap. | ||||
| But because eCash also has a Proof-of-work blockchain in addition to Avalanche, we can leverage | But because eCash also has a Proof-of-work blockchain in addition to Avalanche, we can leverage | ||||
| this to provide a good initial state for Avalanche. The node will first do the normal | this to provide a good initial state for Avalanche. The node will first do the normal | ||||
| Initial Block Download (IBD), and sync to the heaviest PoW chain. Then it will use the | Initial Block Download (IBD), and sync to the heaviest PoW chain. Then it will use | ||||
| Compact Proofs Requests to ask for Proofs from all the Avalanche-aware nodes it is connected to. | Compact Proof Requests to ask for Proofs from all the Avalanche-aware nodes it is connected to. | ||||
| Then, once it has reached a good threshold of stake amount and number of connections, | Then, once it has reached a good threshold of stake amount and number of connections, | ||||
| it activates Avalanche. | it activates Avalanche. | ||||
| [](https://reviews.bitcoinabc.org/D11601) | [](https://reviews.bitcoinabc.org/D11601) | ||||
| What this all means is that the eCash Avalanche implementation is completely trustless and decentralized, | What this all means is that the eCash Avalanche implementation is completely trustless and decentralized, | ||||
| with the following security characteristics: | with the following security characteristics: | ||||
| - It follows the heaviest Proof-of-Work chain to get the initial state, and | - It follows the heaviest Proof-of-Work chain to get the initial state, and | ||||
| ▲ Show 20 Lines • Show All 84 Lines • Show Last 20 Lines | |||||