Cortina 8 does NOT modify the VM interface. If you are running a Custom VM on v1.10.5-v1.10.7, it will work with v1.10.8.
3/ 🚧 ATTENTION OPERATORS 🚧
AvalancheGo@v1.10.8 prunes unused P-Chain block data when starting up for the first time (in the background).
You will see elevated disk/CPU/memory usage for the first ~10 hours after upgrading. **This is expected.**
4/ P-Chain Height Pruning/Indexing
Cortina 8 deletes rejected blocks from disk (we stopped writing them a few releases ago) and reformats the disk format of accepted blocks to be more minimal. Additionally, this release indexes blockIDs by height.
With this release, all chains on the Primary Network are now height indexed. This unblocks the rollout of concurrent block fetching during bootstrapping (which should dramatically reduce the time it takes to sync a new node).
6/ Primary Network Partial Sync
One of the most common feature requests we've heard is to reduce the overhead of running an #Avalanche Subnet.
Cortina 8 introduces a new sync mode that allows **Subnet API** nodes to ONLY INDEX THE P-CHAIN (no X/C).
The mode can reduce Primary Network overhead (CPU/Disk) by 80%+ for node operators that only support Subnet APIs without disabling the ability to verify AWM messages.
8/ PNPS (continued pt. 2)
WARNING: This mode makes it impossible to verify the integrity of P-Chain Atomic Imports (which require validating Atomic Exports on X/C).
You will rely on the consensus of the Primary Network alone to determine tx validity in this mode.
9/ Subnet Validator Diff Regression Fix
Cortina 7 introduced a regression in validator diff calculation on nodes running Subnets (can cause sputtery block production and temporary instability after a validator unstakes). Cortina 8 fixes this.
1/ Unlike other VMs on #Avalanche, HyperVMs now produce blocks continuously (even if empty). #HyperSDKJournal
Why build a block if it doesn't include any state transitions? Although it may sound "wasteful", it has a number of benefits...github.com/ava-labs/hyper…
AWM verification requires fetching the validator set of the P-Chain at the height included in the ProposerVM header of the HyperVM block (computed using reverse diffs).
If there are long periods with no blocks, producers can reference anything between the P-Chain height in the last accepted ProposerVM header and the current P-Chain height.
(It is prohibited to use a height < the P-Chain height in the last accepted header)
1/ Spent the last few days migrating the #Avalanche HyperSDK to use millisecond-denominated block times instead of second-denominated (like all other Avalanche VMs):
Why? So we can remove "block cost" and "surplus fee", of course! ❤️
Block production on Snowman is dynamic (i.e. there is no "slot time" like "every 2s"). Rather, the VM triggers when it wants to build and the consensus engine will ask it to build if it is a preferred producer or no blocks have been produced lately.
3/ I wrote about the unique properties of Snowman/Snowman++ before if you want to dive into this concept:
This version (v1.10.5) is backwards compatible to v1.10.0. It is optional but recommended.
🔍 Release Focus: Add Height-Based Index to X-Chain, Update AWM Message Format, Fix Trace API Regression on C-Chain https://t.co/enQtCSCRyNgithub.com/ava-labs/avala…
2/ 🚧 Compatibility Check: VM Interface (v27) 🚧
Updating the AWM message format is a breaking change to the VM interface (which provides functions to sign/verify said messages).
If you run a Custom VM, you must update it to v27 for AvalancheGo@v1.10.5.
3/ 🚧 Elevated DB Usage on Restart 🚧
AvalancheGo@v1.10.5 creates a height-based index of the X-Chain (used in state sync) when starting up the first time (in the background).
You will see elevated disk/CPU usage for the first ~10 minutes after upgrading. **This is expected.**