guenoledc
commented
2 years ago @sjehan Great thanks for these ideas. We need to spend time together to discuss them in details and see which ones we can implement safely in the scope of the projet.
I understand the idea of the stress testing and it makes lots of sense, but I wonder how operationally it could be done.
On the various formulas, I need to spend more quiet time on it, but surely you can explain
Concerning the simulation, I totally agree the need. Not sure I want to do it in jupiter notebook, but maybe you can teach me this also, so I can participate.
sjehan
@guenoledc @mdekofin
Following the governance meeting, I reread the maths and see no basic flaw in node incentivisation (inflation is included, there is no disadvantage for existing nodes to bring new nodes in, we have limited number of tokens ultimately). The formula is more complex than most of consensus, therefore an online open source simulator is highly recommended so that white paper readers can understand the network dynamics.
However, the carbon footprint methodology is presented as static while it is obviously depending on the network growth.
Governance comments and proposals
In the carbon footprint context, optimizing carbon footprint for a blockchain with very few transactions is easy. https://medium.com/@kavyaub/running-quorum-on-raspberry-pi-e386c1d6fc90
However, this setup will not be sustainable if we have numerous transactions. The blockchain carbon footprint is linear in terms of nodes as we could expect, explained https://tel.archives-ouvertes.fr/tel-03546651/document/
The above studies also shows that the carbon footprint is linear to the gas usage, with small bumps linked to gaz costs being not optimal for some operations compared to their real hardware usage.
Therefore, we could say that globally the blockchain carbon footpring will grow as TxNb Nodes. Each transaction has a carbon footprint linear in gas, and the gas cost is not linear with bytes usage but something in Cste1+Cstes2x^1.3 as is shown in Fig6. https://arxiv.org/pdf/2105.10520.pdf
Therefore, we could build some average carbon cost of the blockchain through its adoption as a formula TxNb NbNodes (cst + cst2*AvgTxBlockSize^1.3).
We expect the node to scale with adoption increasing, otherwise the "carbon footprint" assessment is a bit of a scam (a rasberry Pi 4 device would easily deal with 5 tx/s on an history of a few hundred thousands txs).
Therefore, the carbon footprint of the node should be assessed in a stress test approach by the auditor, where the node has to be tested with a given number of transactions to fill per block.
As a report suggests (Fig3 https://publik.tuwien.ac.at/files/publik_280601.pdf) the node efficiency is not linear with the hardware size. There is an optimal setup that can be manually found in terms of hardware_requirement_and_carbon_footprint / (latency-throughput indicator), since the curb is something like 1/(cst+x^a) where a>0.
The most achievable transaction throughput in clique-derived consensus is 350 TPS with optimal hardware and network latency and bandwidth.
There are approaches to increase this as suggested in the attack description document, by switching in a probabilist way the verify/broadcast sequence depending on whether the network is under attack or not. Such broadcast first appraoch "might" (probably will lead to half because of the RLPx protocol design) lead to 2000 TPS as for the current solana setup, since Solana is also a broadcast-first verify later consensus as well (since block conflicts can be easily merged on solana due to their unique way of keeping time history with VDF).
We also have the existing transaction history log to manage, therefore the stress test should go from 0 to 1 billion transactions.
The node stress test should be done on a matrix (transaction log size, TPS) and the node hardware engineer should adopt a modular scalable approach so that costs could also be minimal at the blockchain intialization, and scale both economically and technically when the network becomes popular.
The carbon footprint should not measure the "actual hardware design" targeting the minimal workload, but the overall footprint computed by a standard network growth in nodes and transactions number (the statistics are available everywhere on many POA networks, or for Ethereum). Therefore, a network growth should be assessed, the node setup should be modified (or not modified) with hot updates on hardware - with no service interruption. We could mark pauses in the stress test to allow the node operator to process to hardware updates through the stress test.
The auditor should note all the infrastructure details and keep the modular/scalable design securely in a vault that will be disclosed. In some sense, the design should be reproducable and reproduced by a partner hardware consulting company to verify the openness of the hardware specifications.
The design should be disclosed after 1 year only, letting the node profit from its optimal technical infrastructure only the first year of usage.
Then, the innovation race will be reset as many infrastructure builders will copy the optimal node technical infrastructure design, moving the average to the previous best miner performance.
The node is then providing shared R&D to the community and should be rewarded as such as well. In effect, it is providing the network infrastructure service to be rewarded, but also some shared R&D service that should be rewarded more if the node prove to be audited as very efficient in the carbonfootprint stress test and prove to providing some ininterrupted service during the first operation year, with no lagged / missed transaction due to subscaling design.
Unfortunately, assessing missed transactions due to hardware insufficiency is difficult (the node could pretend not to have received those missed transactions), therefore we would avoid adding that metrics in the current software design stage.
The reward could be linked to (CarbonFootprint-AVG_CFP)*(NodeAvailability-AVG_NodeAvailability) for the R&D disclosure part.
Similarly, half of the nodes rewards will be staked and released only when the node had no major offline event (more than 1 hour) after 6 months, in a rolling manner, even for nodes with low carbon footprint.