cadlabs / ethereum-economic-model Goto Github PK

Create an assumptions file containing assumptions we make, and adopt from the Economic Report.

See pull request #4 review comments from @marthendalnunes for some initial assumptions.

Possibly include in documentation using Jupyter Book: https://jupyterbook.org/start/overview.html

See TODO in code, from review with @danlessa

• Efficiently research the best way to fit a stochastic process for validator ETH staked
• Design a mechanism for updating the ETH staked in the model
  • Determine semantic and functional reasons for creating a process for ETH staked vs. number of validators
  • Design feedback loop with KPI (e.g. required yield, ETH price volatility) driving staking of ETH

Implement either a static inflation rate, or some reasoned process of dynamic inflation, for the Eth1 inflation rate. The Eth2 inflation is a result of the rewards, penalties, and EIP1559.

Collection of resources for spec and refactors based on new Eth2 proposals:

• https://github.com/adiasg/eth2-quick-merge-poc/blob/master/Eth2-Merge-PoC.ipynb
• https://notes.ethereum.org/@vbuterin/B1mUf6DXO
• https://notes.ethereum.org/@barnabe/HkP3Evp4u
• Altair incentives - ethereum/consensus-specs#2276
• https://hackmd.io/@benjaminion/eth2_news/https%3A%2F%2Fhackmd.io%2F%40benjaminion%2Fwnie2_210328

• Efficiently research the best way to fit a stochastic process for different ETH price scenarios (best case, worst case, base case)
  • Determine the best distributions available for selection
• Design and implement a mechanism for historical price integration from external API source
• Design a mechanism for applying ETH price shocks of different forms, to the stochastic process, historical price, and stable price scenarios

See Economic Report spreadsheet https://docs.google.com/spreadsheets/d/1y18MoYSBLlHZ-ueN9m0a-JpC6tYjqDtpISJ6_WdicdE/, tab ETH1 Tx & Gas Analysis:

• Update 6 months average for gas per transaction eip1559_avg_gas_per_transaction
• Update 6 months average for tx/day eip1559_avg_transactions_per_day
• Validate choice of eip1559_basefee
• Validate choice of eip1559_avg_tip_amount

Notes from review with Barnabe (needs to be validated):

• 1 Gwei for regular TX. MV tx - determined by extractable value - https://insights.deribit.com/market-research/establishing-bounds-for-miner-revenue-in-eip-1559/.
• MEV fixed pie of value. MEV 5-10%, rest 1 Gwei per gas.
• MEV: 5-10% block space, 90% of the tips.

• Implement testing of policies and mechanisms
• Extract logic where necessary to make code more easily testable

@all-contributors please add @uta0x89 for code and maintenance

To review:

• Phase transitions, and use of phases to enable/disable logic at different milestones
• policy_phases(...) in phases.py
• Phase enum in types.py

This issue is created to get the review and input of @danlessa

In the worksession, @rogervs suggested applying the ETH price process as a post-processing transform of ETH rewards and penalties. So essentially the model would only contain ETH states.

To summarize, this would mean:

• Model simplified in runtime
• UX improved being able to efficiently swap ETH price processes without re-running experiment
• All metrics calculated in post-processing which likely improves model performance

The potential downsides of this refactor:

• If we want to make the model more complex and apply shocks to the ETH price process and have the intention of a metric being in a feedback loop causing validators to exit, then we'd need to re-introduce the logic in runtime. Basically, if we want any policy or mechanism to depend on the ETH price, then we'd need to re-introduce it.

The benefit of removing the metrics and ETH price process, assuming we don't need to prematurely optimize the model, is in the UX of being able to swap ETH price processes in post-processing.

See https://hackmd.io/@benschza/S1gT6PvEO for worksession notes.

• Analyse and compare cadCAD web app frameworks and integrations (e.g. Streamlit, HoloViews, Dash (Plotly))
• Create a POC integration of a minimal Eth2 cadCAD model into the web app framework with illustrative parameter selection/scenarios (e.g. drop-downs, sliders, various options)
• Draft layout of the Eth2 Masterclass validator economics dashboard using the chosen web app framework in close collaboration with Edu team (research and motivate options)

Currently, the model modules are as follows:

• accounting.py
• ethereum.py
• proof_of_stake.py
• eip1559.py
• etc.

Consider refactoring if necessary to make these classifications more clear. Barnabe suggested finalization and justification as concepts worth considering: https://our.status.im/two-point-oh-justification-and-finalization/ . @rogervs suggested looking at the Eth2 spec. test suite to see what the architecture is.

Accessibility and value for learning should be prioritized, and sticking to the existing Eth2 spec and standard terminology.

See https://www.python.org/dev/peps/pep-0257/

Standard multiline docstrings. No argument descriptions apart from non-cadCAD functions.

The current hypothesis is that we will not implement phases, and will instead make the assumption that the model is operating post-merge.

The following mechanisms affect validator yield economics, and are implemented in phases:

• EIP1559 implemented (only rewards Eth1 miners until phase 2)
• Transactions being enabled in phase 2 (EIP1559 rewards both Eth1 miners and Eth2 validators)
• Supply inflation - PoW block rewards gradually decrease (big assumption, under current network conditions?):

See https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/

In Phase 0, 1, and 2 the main PoW chain (Eth1) will remain live while testing and transitioning is happening on the Eth2 chain. This means that rewards will be paid to both Ethereum 2.0 validators as well as the normal PoW block rewards. Therefore, the combined inflation of the two chains may spike initially but then start to trend towards the 0-1% range as the PoW chain is gradually de-emphasized.

Hey all, thanks so much for creating such a great resource for the community! A few suggestions from checking back in on the site:

• change the default "community consensus (March 2022)" to June 2022, as June seems much more likely and we are already in March. (same for optimistic I guess)
• it also looks like the issuance data is stuck in August 2021, would it be possible to backfill this data?
• looks like there are two "Proof of Stake" items represented in purple and red

As discussed in the work session on Friday 26th March, the following is a brainstorm of a MVP implementation of a validator entry/exit process that depends on the current system state or metrics. It is undecided if we will implement this, or rather suggest it as a future addition to the model.

Different scenarios for validator exit:

• Excessive penalties and slashing in extreme scenarios (this would only impact those being penalized, perhaps causing them to exit)
• A crashing ETH price, a loss of confidence in the long term value of ETH - investor archetype leaves
• Cost of validating increases causing validators to exit or move to another validator group (cloud, SaaS, DIY, etc.) (unclear what would cause this though)
• RSAVY type metric reaches threshold (window function applied to introduce a long term outlook on returns)

The question of how to model a distribution for those who decide to leave in these conditions was discussed:

• Look at historical ETH price events, such as 2017 market price crash, and see distribution of those who HODL vs. liquidate - unclear exactly how to get these metrics, would need analysis of wallet activity likely, or approximation from something like exchange or Uniswap pool activity?
• We could assume DIY == HODL, and make other such similar assumptions to create a model

• Check out LucidChart diff. spec diagram: https://lucid.app/lucidchart/470a21cc-6ba5-49ed-ae54-22a80bc1ab43/edit?page=KXzjCn3DR_H2#
• Clone the repo and execute the default experiment
• Review the open PR with the MVP implementation updates