Anyone aware of a consensus paper that uses a “loss-y model” for message delivery rather than the typical “eventually delivered” assumption? The papers I’ve read recently uniformly assume messages will eventually be delivered but never dropped (unlike a real-world setting over a WAN with periodically rebooting nodes) and leave it as an exercise to the reader to craft sound mechanisms to recover from “inevitable gaps”.

I am launching a new company, @commonwarexyz, because I think the communities that will be leaders in the onchain era will take a different path than the ones already paved: specialization.

https://twitter.com/_patrickogrady/status/1821607372424671415

To accelerate developers that share this perspective, Commonware is building an open, Rust-based blockchain framework architected for excessive throughput, tractable modification, and embedded interoperability.

Is it possible to make a large (> 500 validators) and robust (liveness and safety up to f < n/3 byzantine faults) blockchain snappy (~1s finality)? 1/ Over the last few months, @stephenbuttolph and I explored this question.

Vena: Optimistically Responsive Consensus Over Large Validator Sets

hackmd.io/@patrickogrady… 1/ Vena is an optimistically responsive consensus protocol in the partially synchronous network model tailored for deployment on public blockchains with large validator sets.

1/ 🛠️ 🛠️ #Avalanche Durango 6 is out: 🛠️ 🛠️

This version (v1.11.6) is backwards compatible to v1.11.0. It is optional but recommended for all operators.

🔍 Focus: secp256r1 Staking Keys + Improve C-Chain State Sync Reliability + Fix Connection Tracking github.com/ava-labs/avala…


2/ 🚧 Attn Node Operators: Metrics Refresh 🚧

Durango 6 overhauls the format of many of AvalancheGo's exported metrics. This new format is easier to work with when creating dashboards and cheaper for hosted metrics platforms to ingest.

This work will continue in Durango 7.

1/ 🛠️ 🛠️ #Avalanche Durango 5 is out: 🛠️ 🛠️

This version (v1.11.5) is backwards compatible to v1.11.0. It is optional but strongly recommended for all operators.

🔍 Focus: X/P/C Bootstrapping Optimization + Beta Consolidation + Consensus Engine Fixesgithub.com/ava-labs/avala… 2/ ✅ Compatibility Check: VM Interface (v35) ✅

Durango 5 DOES NOT modify the VM interface. If you are running a Custom VM on v1.11.3-v1.11.4 (like Subnet-EVM@v0.6.3), it will work with v1.11.5.

github.com/ava-labs/subne…

Processing 5 Billion Micropayments (at 100k TPS) with Avalanche Vryx and Vilmo

hackmd.io/@patrickogrady… Over the last few days, the first Vryx devnet processed 5 billion micropayments at a sustained rate of 100,000 transactions per second (TPS).

This test involved 10M active accounts (2.5M active every 60 seconds and 95k active every second) sending transfers to each other.

🛠️ 🛠️ #Avalanche Durango 3 is out: 🛠️ 🛠️

This version (v1.11.3) is backwards compatible to v1.11.0. It is optional but strongly recommended for all node operators.

🔍 Focus: Post-Durango Cleanup + Push Gossip Refactor (Phase 2) + BLS on Local Networks github.com/ava-labs/avala…




🚧 Compatibility Check: VM Interface (v35) 🚧

This release introduces VM Interface v35 to support changes to the AppSender Interface (AppGossip).

If you are running a Subnet, make sure to upgrade your Custom VM to v35 (subnet-evm@v0.6.3) before running it with v1.11.3.

1/ 🛠️ 🛠️ #Avalanche Durango 2 is out: 🛠️ 🛠️

This version (v1.11.2) is backwards compatible to v1.11.0. It is optional but strongly recommended for all node operators.

🔍 Focus: Redesign Push Gossip on the X/P/C-Chaingithub.com/ava-labs/avala… 2/ 🚧 Compatibility Check: VM Interface (v34) 🚧

Durango 2 adds support for message-specific gossip parameters to the VM interface (used in the push gossip redesign).

If you run a Subnet, you must update your VM to v34 for v1.11.2 compatibility.

1/ 🌀 The Avalanche Interoperability Era Starts at 11 AM ET on 3/6 🌀

Today, the production code (AvalancheGo@v1.11.0) for the proposed Durango Upgrade was published. If sufficient stake supports Durango, it will activate on Mainnet at 11 AM ET on Wednesday, March 6th, 2024. 2/ Durango contains ACPs that are not compatible with < v1.11.0 (Cortina).

If Durango activates and you do not upgrade your node **before** the activation time, your node will be unable to process new blocks and will be marked as offline by other nodes (impacting uptime).

At 11 AM ET, the proposed Durango Upgrade successfully activated on the #Avalanche Fuji Testnet

TL;DR 🌀🌀🌀 (Fuji C-Chain can now verify incoming Avalanche Warp Messages)

avax.network/blog/durango-a… Here is the FIRST C-Chain <> Subnet Avalanche Warp Message (using Teleporter)

Export from C-Chain:

Import into Dispatch Subnet: subnets-test.avax.network/c-chain/tx/0x3…
subnets-test.avax.network/dispatch/tx/0x…

🌀 Welcome to the #Avalanche Interoperability Age 🌀

Today, the pre-release code for a proposed upgrade to the Avalanche Network (AWM Support on C-Chain) was published and will activate on the Fuji Testnet at 11 A.M. ET on Tuesday, February 13th, 2024.

github.com/ava-labs/avala… This proposed upgrade, codenamed Durango, consists of Avalanche Community Proposals (ACPs):

[23] P-Chain Native Transfers:

[24] Activate Shanghai EIPs on C-Chain:

[25] Virtual Machine Application Errors: github.com/avalanche-foun…
github.com/avalanche-foun…
github.com/avalanche-foun…

1/ 🛠️ 🛠️ #Avalanche Cortina 19 is out: 🛠️ 🛠️

This version (v1.10.19) is backwards compatible to v1.10.0. It is optional but recommended.

🔍 Focus: Options Before Verification + Fix P-Chain Validator Set Race + Fix C-Chain Bloom Filter Reconstruction github.com/ava-labs/avala…


2/ Options Before Verification

To prepare for deferred verification, support to invoke "Options" before "Verify" on "ProposalBlocks" has been added. This block type is used in the P-Chain.

github.com/ava-labs/avala…

ICYMI The Vryx Spec is OUT!

Vryx is a decoupled state machine replication (DSMR) construction that employs:

1) account fraud proofs
2) account partitioning
3) nonce-less transactions
4) transaction filtering

to robustly scale the throughput (TPS) of the #Avalanche HyperSDK


Thanks to @Timccopeland and @TheBlock__ for covering the release of Vryx last Friday 🙏

https://x.com/TheBlock__/status/1750942947955105984?s=20

1/ 🛠️ 🛠️ #Avalanche Cortina 18 is out: 🛠️ 🛠️

This version (v1.10.18) is backwards compatible to v1.10.0. It is optional but recommended.

🔍 Release Focus: ACP Signaling + Peer IP Discovery Optimization + Remove Pending Stakers (unactivated) github.com/ava-labs/avala…




2/ 🚧 Compatibility Check: VM Interface (v31) 🚧

Cortina 18 introduces numerous breaking changes to the VM interface:
*
*
*

If you run a Subnet, you must update your VM to v31 for v1.10.18 compatibility.github.com/ava-labs/avala…
github.com/ava-labs/avala…
github.com/ava-labs/avala…

transactions will expand to fill any and all block space as long as the "perceived incremental value" (PIV) from tx inclusion > fee

if there is "perceived positive net value" (PPNV) to take, someone will always seek it regardless of the tx fee

(i'm talking about inscriptions) typically, PIV can be captured in a single transaction (you don't need a new tx per basis point of arbitrage) but many on-chain interactions in the class of "open mints" purposely discretize interaction such that the PIV a single tx can capture is capped (1 tx per Y claim)

1/ 🛠️ 🛠️ #Avalanche Cortina 16 is out: 🛠️ 🛠️

This version (v1.10.16) is backwards compatible to v1.10.0. It is optional but recommended.

🔍 Release Focus: Optional Tx Indexing on C-Chain + Concurrent Trie Prefetching + Track All Subnet Validator Sets github.com/ava-labs/avala…




2/ Compatibility Check: VM Interface (v30)

Cortina 16 does NOT modify the VM interface. If you are running a Custom VM on v1.10.15, it will work with v1.10.16.

1/ 🛠️ 🛠️ #Avalanche Cortina 15 is out: 🛠️ 🛠️

This version (v1.10.15) is backwards compatible to v1.10.0. It is optional but recommended.

🔍 Release Focus: Experimental PebbleDB Support + BaseTx Support on P-Chain + MerkleDB Memory Optimizations github.com/ava-labs/avala…
2/ 🚧 Compatibility Check: VM Interface (v30) 🚧

The "database.Manager" was removed in Cortina 15. Corresponding support in the VM interface has also been removed.

If you run a Custom VM, you must update it to v30 for AvalancheGo@v1.10.15 compatibility.

github.com/ava-labs/avala…

1/ Following a lot of great conversation over the last few days about "[Draft Proposal] The Path to 100k Subnets: Overhauling the Relationship between the Avalanche Primary Network and Subnets", I decided to post an #Avalanche Community Proposal (ACP):

github.com/avalanche-foun…

https://twitter.com/TheBlock__/status/1719369915491082514

2/ If you'd like to comment on "ACP-13: Subnet-Only Validators (SOVs)", you can share your thoughts on the dedicated GitHub Discussion:

github.com/avalanche-foun…

1/ 🛠️ 🛠️ #Avalanche Cortina 14 is out: 🛠️ 🛠️

This version (v1.10.14) is backwards compatible to v1.10.0. It is optional but recommended.

🔍 Release Focus: Add TransferSubnetOwnershipTx + Redesign Validator Set Management + Add PebbleDB Implementation github.com/ava-labs/avala…


2/ ✅ Compatibility Check: VM Interface (v29) ✅

Cortina 14 does NOT modify the VM interface. If you are running a Custom VM on v1.10.13, it will work with v1.10.14.

1/ 🛠️ 🛠️ #Avalanche Cortina 13 is out: 🛠️ 🛠️

This version (v1.10.13) is backwards compatible to v1.10.0. It is optional but recommended.

🔍 Release Focus: Reduce Memory Allocs in MerkleDB Path Generation + Refactor API Locking + Add Prefetcher Inferface github.com/ava-labs/avala…
2/ 🚧 Compatibility Check: VM Interface (v29) 🚧

lock_options was removed from the Handler proto message because it is no longer supported in AvalancheGo.

If you run a Custom VM, you must update it to v29 for AvalancheGo@v1.10.13 compatibility.