Apricot Phase Four will activate on the Fuji Testnet at 5 p.m. EDT (9 p.m. UTC) on Thursday, September 16th. The Avalanche Mainnet activation time will be announced in the coming days.

This morning, the pre-release code was published for Phase Four of the Apricot Upgrade (“AP4”), which will activate at 5 p.m. EDT (9 p.m. UTC) on Thursday, September 16th on the Fuji Testnet. Note, this pre-release code only works on Fuji. If you run it on Mainnet, it will exit on startup.

Pending a successful AP4 activation on Fuji, the Avalanche Mainnet AP4 activation time will be announced and the official AP4 AvalancheGo release (v1.6.0) will be published.

This upgrade includes protocol optimizations that are not compatible with AvalancheGo versions < v1.6.0. If you run a node on Fuji Testnet, it is recommended that you update your software to AvalancheGo >= v1.6.0 before the activation time on Fuji. If you are a Mainnet node operator, there is no action required until the official AvalancheGo@v1.6.0 code is published.

Optimization 1: Snowman++ (Reducing MEV & Contention)

In Avalanche, any node can produce a block at any time as long as that block contains some non-zero number of fee-paying transactions. After producing a valid block, it is up to the consensus engine, known as Snowman, to finalize one of the many potentially conflicting blocks at any given height. Regardless of the magnitude of the contention, Snowman eventually clears through all conflicts and accepts 1 block at each height (rejecting all others). As a general principle, however, the lower the contention, the faster the time to finality (less resources spent resolving conflicts).

Without the introduction of any optimizations, contention on the Avalanche network would increase commensurately with additional usage (as the competition for extractable value on-chain intensifies with additional TVL). This story has already started to play out as some network participants have begun to modify the node software to better take advantage of “Miner/Maximal Extractable Value” (MEV) by bypassing some of the throttling mechanisms meant to deter overly aggressive block production.

For those unfamiliar with MEV, it is generally considered “the total value that can be extracted permissionlessly (i.e. without any special rights) from the re-ordering, insertion or censorship of transactions within a block being produced” (from Flashbots). In the context of Snowman’s leaderless block production, a slightly broader definition is more applicable, one that also covers the value that can be extracted from modifying the time a block is produced and/or the parent referenced by the block being produced.

To preserve Avalanche’s fast time to finality and ensure node resource requirements don’t increase proportionally with (exponential) user growth, some low-hanging optimizations are warranted that reduce unnecessary contention and more accurately charge for expensive interactions with the network. At Ava Labs, we started a R&D effort ~6 months ago to research how to optimize the protocol to systemically limit the ability for block producers to put strain on the network (and on all the validators in the network) in their vicious competition with each other to beat each other out to perform particular on-chain interactions first. Today, that effort is unveiled: Snowman++.

Snowman++ is implemented as an overlay to Snowman (automatically applied to all user-created VMs based on Snowman) that restricts the amount of contention any given node can create by randomly enlarging the subset of validators that can produce a block at a given height over time. This subset of validators (and the priority for block production) is perturbed after the production of each block so the likelihood of producing the next block does not increase if a validator produced the previous block. Snowman++ does not make any user-facing modifications, so exchanges, wallets, etc. are not required to make any changes to their integrations (other than upgrading to AvalancheGo@v1.6.0, if they run a node). You can read the full Snowman++ technical specification here.

Engineers at Ava Labs found that Snowman++ reduced the amount of contention seen in highly adversarial environments by up to ~99.7%, compared to Snowman. This results in a direct reduction in validator bandwidth/CPU/disk IO usage in these scenarios.

Optimization 2: C-Chain Fee Reductions

Apricot Phase 3 migrated the C-Chain to use a new dynamic fee algorithm called “Moderato”. This algorithm targets a specific network utilization over time and adjusts the minimum fee any transaction must pay to be included in a block based on the amount of activity (“gas burned”) over the last 10 seconds. Since AP3 activation, gas price has averaged ~98.2 nAVAX, a ~56% reduction from AP2. The hourly average gas price over this time period is plotted below:

Generally speaking, it is responsible to only adjust the fee parameterization of a network when some innovation limits the net impact of the change to be somewhere close to neutral. For example, when DB IO goes down ~50%, fees can simultaneously be reduced by ~50%. In this vein, the gas price range on the C-Chain has been expanded to 25 nAVAX-1000 nAVAX from its previous range of 75 nAVAX-225 nAVAX, thanks to the resource reduction introduced by Snowman++, especially under load. Additionally, the “Moderato” smoothing parameters have been tuned such that the fee will increase/decrease much less rapidly, based on feedback from the community.

Optimization 3: Block-Based Fees

Last but certainly not least, Apricot Phase Four introduces the notion of a block fee that must be paid by transactions in a block if it is produced faster than the block target rate. Because any node can produce a block at any time in Snowman, it is important that blocks fairly compensate the network (i.e. burn sufficient AVAX) for the strain they generate, especially when produced in very quick succession.

The block fee is a continuously evaluated function (like “Moderato”) that increases/decreases in value based on how many blocks are being produced faster than the block target rate. The block fee is paid by the “effective tip” of all the transactions in a block, where “effective tip” is the gas price paid over the minimum required gas price multiplied by the gas used by the transaction (i.e. the unnecessary burn). This looks something like: (“gasPrice” — “minGasPrice”) * “gasUsed”.

Most people (~99%) that interact with Avalanche, will never even notice that block-based fees exist because they don’t go out of their way to expedite the inclusion of their transactions into blocks (typically there is no need to do so as the average time-to-finality is 1–2s). However, the people that do attempt to produce blocks at an aggressive clip will be charged for that ability.

Useful Links

• Apricot Phase Four Upgrade code can be found here.
• A tutorial for upgrading your node is available here.
• If you have any questions, please connect with the Ava Labs developer team here.
• For a full list of all the items that are targeted in upcoming upgrades, check out the roadmap.

FAQ

How do I upgrade my node?

The process to upgrade to AvalancheGo v1.6.0 is the same as any other upgrade. If you build from source, run the build script as before. If you use the pre-compiled binaries, invoke them as before. If you use the installer script, use that as before.

Once you start AvalancheGo v1.6.0, you do not need to do anything else. More information on updating a node can be found here. As a reminder, it is best practice to have a backup of your staking key/certificate.

What are the minimum/maximum gas prices?

25 nAVAX (66% reduction from AP3) and 1000 nAVAX, respectively.

Please note that the maximum gas price is not capped by the static gas price of AP2 (225 nAVAX). If you don’t migrate to use the built-in dynamic fee endpoints prior to AP4 activation, it is possible that the processing of your transactions will be delayed (if the minimum network gas price rises above 225 nAVAX).

You can get the current suggested gas price by calling the eth_gasPrice API method. For example:

I use Metamask. Do I need to change anything?

No. Metamask will automatically account for the new minimum/maximum gas price once they go into effect (just like it did for the introduction of dynamic fees in AP3).

Do I have to upgrade my node?

If you don’t upgrade your validator to v1.6.0 before the Avalanche Mainnet activation date (will be shared in coming days), your node will be marked as offline and other nodes will report your node as having lower uptime, which may jeopardize your staking rewards.

Is there any change in hardware requirements?

No.

Will updating decrease my validator’s uptime?

No.

I think something is wrong. What should I do?

First, make sure that you’ve read the documentation thoroughly and searched the FAQs. It might answer your question somewhere. If you don’t see the answer, go to our Discord server and search for your question. If it has not already been asked, please post it in the most appropriate channel.

---

Apricot Phase Four: Snowman++ and Reduced C-Chain Transaction Fees was originally published in Avalanche on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source