# Ideas for The Way Forward
## 2024
Isaac:
* fix erigon (repair and ongoing maintenance)
* geth etc-lite-patch spiral support (ongoing maintenance)
* fix cross client testing so we can actually generate tests, they way dmitri left us doesn't work (at least for me), i dropped the ball on this for spiral and we're basically without dedicated x-client tests for it
* maybe work with exchanges for sensible confirmation delays
* move metrics and monitoring to dedicated team infrastructure, alerts included
* dockerized geth with vpn/socks in the box? for privacy
* fix or at least address the apparent dag generation issue
* monetary policy 5M20 is coming at block 20M, brace ourselves for 2.6*0.8 rewards
* maybe EOF and/or subroutines for the EVM, maybe with or without ETH
* continuing education programs for coopers
Christos:
* upgrade enodexp or use one of the new node-cralwers (https://hackmd.io/@angaz/BJ-kJ3bIT)
* does it make sense to create a script that converts the Filler tests to scripts that can run to actual chains, like we did for this hard-fork on Mordor, so as we can test pre and post condition on shadow forks. I am not sure that it's really possible to automate this logic, but we can try it
* update forkmon code and make it nestable in etcnodes.org. Currently forkmon config is quite is to mess stuff, as it reads all the info from the config and not actually from the nodes
* explore Layer 2 solutions on ETC
Diego:
* JSON-RPC regression testing (reported on Telegram)
* Releases automated testing (Eris incident)
* Test mining software
* Move Graphana to Ansible, unify Graphana instances (or maybe move to https://grafana.com/pricing/?pg=prod-cloud&plcmt=pricing-details)
* Explore 1559 without burning fees
* Explore Nethermind+ETC
* Investigate on Verkle trees
---
### Ethereum Classic @ Google Big Query
Use `ethereum-etl` and pipe block data to BQ.
This should exist because
- Big Query is super nice to have for adhoc queries
- adhoc queries like BQ provides are very important for __security and response reasons__.
### core-geth
#### (re: v1.12.9 bug) improve system load tests
v1.12.9 had a bug that made it into production; CPU on the machine running `geth` maxed out.
We should not just sweep this under the rug.
We should set up tests to make sure it doesn't happen again.
Use the Jenkins on AWS to run sync tests (`--exit-when-finished`)?
How to catch this bug:
- Metrics ingestion like `Influx` plus `alertmanager` with `geth --metrics` can find CPU use for geth and system and alerts can be configured around it
- Are there other, simpler ways, like using Go profiler directly?
System load tests are important, too, for potential issues
like block processing attacks. __Security__.
#### core-geth: other things
- [ ] remove parity config schema support
- [ ] remove aleth config schema support
- [ ] remove multi-geth config schema support
- [ ] drop cmd/ancient-mem-store
- [ ] `--exit-when='function() {};'`
- [ ] ports, cli, fs footprint; consistency tests (respecting `--chain`, in particular);
+ eg. `authrpc.port`'s new default caused very quiet conflict for me, resulting in geth not running properly
- [ ] `--ports-shift=xx` which shifts all ports up by the entered value. Parity had this feature, and I have it on a bash script which I find very helpful when running multiple nodes at my machine
- :+1:<sub>isaac</sub> love it
- [ ] investigate checkpoint assertions for ETC
- Ethereum implements and continually bumps hardcoded checkpoint values for their network. Ethereum Classic has never done this. There exists `cmd/checkpoint-admin`.
- What is ETC missing without this? Is it worth it?
- How then, to go about adding it, if we want to.
### Besu
- ETC Modularization
- Complete Junit5 migration
- Analyze if it's possible to move current threading model to Vert.x contexts
- Translate Antoine's [workshop] (https://www.youtube.com/live/4pCxwuNRaKg) to spanish
- Analyze current testing pipeline (i.e. canaries) and, if those are under Hyperledger's umbrella, request adding ETC
### Improve network mapping
Currently https://etclabscore.github.io/nodes-interface/
is about as good a picture as we have of the network.
This picture is quite limited. Let's improve it.
Understanding the network (in real time) is __security relevant__.
- p2p/federated protocol for better sharing neighbors (and known-neighbors of neighbors?)
### Cross-client networking tests
- `hive`, `ageth`...
Currently, cross-client tests for Ethereum Classic are limited
to state and other on-chain consensus tests (eg. difficulty).
It would be good to test `besu` with `core-geth` (and others, see __New ETC clients__) to ensure that they peer, share data, and generally cooperate.
This provides value both during "normal" testing, as well as in pre-fork and oh-fuck situations.
- [ ] Programmatically, as a CI step.
- [ ] On dynamic hardware (eg. ansible, terraform).
- [ ] Transaction fuzzing
- [ ] Mine through some pools (ideally, CPU bounded so we don't increase difficulty so much)
### Incident analysis
- [ ] https://github.com/ethereum/go-ethereum/issues/24720
This one is good to know it exists so as we use those functions. Also, we can maybe contribute to it + there is an effort of standrdazing some `debug_*` methods accross clients and I am not sure if Besu has all of them.
### New ETC clients
- [ ] :package: We could set up releases and associated artifacts for these.
- :whale: etccooperative/erigon has a `.github/workflows/release.yml` that should work for us with a `DOCKERHUB_KEY`
__[etccooperative/erigon@`devel+classic`](https://github.com/ETCCooperative/erigon)__
A version of erigon that supports ETC, also with a minimal code footprint.
See also [etccooperative/erigon-lib](https://github.com/ETCCooperative/erigon-lib).
__[etclabscore/ethereum.go-ethereum@`etc-lite-patch`](https://github.com/etclabscore/ethereum.go-ethereum/tree/etc-lite-patch)__
A version of go-ethereum that supports ETC with a minimal code footprint,
streamlining upstream merge to a point of near-automation.
- [ ] Maybe we can move the development branch (currently https://github.com/etclabscore/ethereum.go-ethereum/pull/16) to
- github.com/etclabscore/go-ethereum/tree/master+classic
- github.com/etclabscore/go-ethereum/tree/release/1.10+classic
This would be analogous to the version control pattern at etccooperative/erigon.
### Infrastructure
- [ ] (Isaac) Move our [shared multi-instance metrics dashboard](dash.metrics.etccore.in/) to a shared VPS.
- Source: https://github.com/etclabscore/metrics.etccore.in.
### Clean up the MESS
### Governance
### Extract etclabscore/go-etc-common-lib
### Protocol
- Discuss about adding support for EIP-1559 transactions (codename: iceman)
- Catch up with [ETH Shanghai](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)