(0/11) Last Friday, we provided our first recap of the engineering work that @avalabsofficial is doing to support the @avalancheavax community: https://twitter.com/avalancheavax/status/1385716690714046465 https://twitter.com/bitcrono/status/1387465433003986958
1) Recently, we’ve spent a lot of time behind the scenes on the C-Chain to support the growth you alluded to in your earlier message. It is now one of the most popular networks by fees paid (a proxy for high-value activity/demand for block space): https://twitter.com/kevinsekniqi/status/1379043085330620421
2) We also gave some major
to the API platform ( http://api.avax.network ), which now serves 3+ billion requests each month. Turns out you can’t just keep adding nodes to support a load like that unless you particularly enjoy setting money on fire.

3) Lastly, we shipped a new indexer for avalanchego that makes it easier for integrators to ingest chain data (supports X, P, and C). Generalizing an indexing abstraction to work across different VMs and making it performant takes time to get right.
4) The work we’ve been doing to fortify the C-Chain and improve indexing will be reused extensively in subnet upgrades (which use the same underlying orchestration mechanism). Subnets are a big part of the
that makes @avalancheavax special and they are always on our mind.

5) Subnets uniquely empower @avalancheavax to keep scaling and improving over time. Traffic/state can scale horizontally and new features can be rolled out without breaking things (the complexity and cost of maintaining existing integrations is super overlooked IMO).
6) Don’t need to access the state of other contracts? Move to a subnet with less traffic and lower fees.
Want to rewrite a VM? Spin up a new subnet and users that want to use it can move their assets over to it. Anyone still using the old instance of the VM is unaffected.
Want to rewrite a VM? Spin up a new subnet and users that want to use it can move their assets over to it. Anyone still using the old instance of the VM is unaffected.
7) All this being said, subnets won't be as successful if avalanchego isn't robust and performant enough to be run by thousands of validators. Like the indexer, this effort is complicated by the need to ensure optimizations work with all VMs, each with their own state and logic.
8) Have you ever tried to run a node for one of the projects you mentioned? Get your checkbook, dedicated gigabit connection, and AWS cluster ready to roll because that's what it will take.
There's a reason why there are more validators on @avalancheavax than anywhere else.
There's a reason why there are more validators on @avalancheavax than anywhere else.
9) The unglamorous work of making this happen never really grabs the same attention as new features but is just as important to the long-term health of the network.
10) @avalabsofficial is hard at work on all the exciting features you mentioned (for release in avalanchego) but is making sure they're robust and performant enough for all 920+ validators to run without issue. We're scaling up our eng team and shipping more code than ever.

11) As a reminder, you can follow along each week on all the work @avalabsofficial is doing in our new engineering blog.
If being part of the fun interests you, send over a resume to us at: https://jobs.lever.co/avalabs?lever-via=GmiuXLHCCx
We
remote work and hire all over the world!
If being part of the fun interests you, send over a resume to us at: https://jobs.lever.co/avalabs?lever-via=GmiuXLHCCx
We
