This commit is contained in:
mvonsteinkirch 2023-02-08 09:08:45 -08:00
parent bf818f2682
commit d3a292bfd1
133 changed files with 26 additions and 40 deletions

View file

@ -0,0 +1,29 @@
## mev on arbitrum
<br>
### tl; dr
<br>
* optimistic rollup
* currently has a centralized sequencer and whitelisted proof validation while having upgradable contracts
<br>
----
### in this dir
<br>
* [gmx](gmx.md)
<br>
---
### resources
* [transaction ordering policy](https://research.arbitrum.io/t/transaction-ordering-policy/127)
* [fair ordering sequencing](fair_ordering_sequencing.md)

View file

@ -0,0 +1,8 @@
## fair ordering sequencing
<br>
### tl; dr
* need a bond that is slashable and a fair ordring protocol (picking a fair sequence of events to publish)
* users pay for the right to extract MEV over a period through the opportunity cost per block times the number of blocks staked

View file

@ -0,0 +1,46 @@
## gmx
<br>
### tl; dr
<br>
* decentralized spot and perpetual futures exchange, built on arbitrum and avalanche.
* enables traders to open up to 50x leveraged long or short positions via borrowing from a multi-asset pool known as GLP (that earns lp fees through market making, swap fees, leverage trading, and asset rebalancing).
* GLPs functions as the counterparty, as it accrues values when traders loses, and devalue when traders win. GLP accrues 70% of all trading fees, while stakers of the protocol governance token, earn 30%. GLP is also emerging as a form of collateral, with lending protocols integrating the LP token into their product offerings.
* native token $GMX functions as a governance, utility, and value-accrual token. all collected fees fo to the GMX fee pool, which issues fee rewards (e.g., ETH/AVAX).
<br>
---
### tokenomics
<br>
* $GMX:
* participate in 30% of protocol fees
* earn escrowed GMX (esGMX)
* earn multiple points that boost yields
* $esGMX
*
<br>
<img width="739" src="https://user-images.githubusercontent.com/1130416/217584094-7d12706a-527c-4642-babd-0c554946c229.png">
<br>
---
### resources
<br>
* [gmx price oracle abuse](https://twitter.com/ChainsightLabs/status/1580208615654584321?s=20&t=-FG5kQ_7kAKhLnbuk05wSg)

View file

@ -0,0 +1,25 @@
## mev on avalanche
<br>
### tl; dr
<br>
<br>
---
### resources
<br>
* [gmx resources](https://github.com/go-outside-labs/mev-toolkit/blob/main/MEV_on_Arbitrum/gmx.md)
* [chainsight on avax mev](https://avax.chainsight.dev/)
* [all fair in arb and mev on avalanche](https://www.ddmckinnon.com/2022/11/27/all-is-fair-in-arb-and-mev-on-avalanche-c-chain/)
* [gmx price oracle abuse](https://twitter.com/ChainsightLabs/status/1580208615654584321?s=20&t=-FG5kQ_7kAKhLnbuk05wSg)

View file

@ -0,0 +1,7 @@
## mev on binance
<br>
### resources
* [mev-bsc](https://github.com/0x2mev/mev-bsc)

View file

@ -0,0 +1,20 @@
## 🍫 mev on cosmos
### tl; dr
<br>
----
### resources
* [nice review on cosmos and tendermint, by maven11](https://maven11.substack.com/p/the-application-specific-chain-thesis)
* [skip.money](https://skip.money)
* [satellite mev dashboard on cosmos](https://satellite.skip.money/)
* [thyborg twitter thread](https://twitter.com/Thyborg_/status/1547898785933639684)
* [FairBlock, frontrunning protection](https://github.com/pememoni/FairBlock)
* [Meka.tech](https://meka.tech/thesis)

View file

@ -0,0 +1,125 @@
## mev and proof-of-state ethereum
<br>
<img width="500" src="https://user-images.githubusercontent.com/1130416/204161522-07e49b61-5163-42a1-ba5d-7ba45db4b3dd.png">
<br>
### in this dir
<br>
* [running nodes and validators](running-a-node.md)
* [advanced resources on running nodes and validators](running-a-node-advanced.md)
* [geth on kubernetes](geth_and_k8s)
* [dets and specs for relays](relays.md)
* [pos consensus mechanisms](pos_consensus_mechanisms.md)
* [blockspaces](blockspace.md)
* [basic evm](evm-knowledge.md)
* [eip-1559](eip-1559.md)
* [the mempool](the_mempool.md)
* [searcher builder validator/sequencer](searcher-builder-validator-sequencer/)
* [glossary](glossary.md)
<br>
---
### nodes and validators stats
<br>
* [ethereum.org launchpad](https://launchpad.ethereum.org/en/)
* [official beacon chain explorer](https://beaconscan.com/)
* [another beacon chain explorer](https://beaconcha.in/)
* [prater/goerli beacon chain explorer](https://prater.beaconcha.in/)
* [beacon chain validator ratings](https://www.rated.network/)
* [list of nodes as a service](https://ethereumnodes.com/)
* [node watch](https://www.nodewatch.io/)
* [archive node access](https://archivenode.io/)
* [list of nodes as a service](https://ethereum.org/en/developers/docs/nodes-and-clients/nodes-as-a-service/)
* [economics post-merge](https://docs.google.com/spreadsheets/d/15tmPOvOgi3wKxJw7KQJKoUe-uonbYR6HF7u83LR5Mj4/edit#gid=1018097491)
* [exploring the first 1k epochs of eth, by barnabe.eth](https://ethereum.github.io/rig/posdata/notebooks/mainnet_explore.html)
<br>
#### consensus layer
* [client diversity vs. prysm usage](https://pools.invis.cloud/)
* [consensus clients comparisons](https://www.slashed.info/)
<br>
#### execution layer
* [ethereum mainnet stats](https://ethernodes.org/)
* [execution clients tracker](https://etherscan.io/nodetracker)
<br>
####### both layers
* [project sunshine](https://ethsunshine.com/)
* [clients diversity](https://clientdiversity.org/)
<br>
----
### clients
<br>
#### execution layer
* [geth](https://geth.ethereum.org/)
* [nethermind](https://nethermind.io/)
* [besu](https://besu.hyperledger.org/en/stable/)
* [erigon](https://github.com/ledgerwatch/erigon)
* [akula](https://akula.app/)
* [execution api specification](https://github.com/ethereum/execution-apis)
<br>
#### consensus layer
* [prysm](https://github.com/prysmaticlabs/prysm)
* [lighthouse](https://github.com/sigp/lighthouse)
* [teku](https://github.com/ConsenSys/teku)
* [nimbus](https://nimbus.team/)
* [lodestar](https://lodestar.chainsafe.io/)
<br>
#### engine api
* [engine api docs](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md)
* [ethereum json-rpc api](https://ethereum.org/en/developers/docs/apis/json-rpc/)
<br>
---
### resources
<br>
* [resources on private order flows](https://github.com/go-outside-labs/mev-toolkit/tree/main/private_order_flows)
* [proposer/block builder separation-friendly fee market designs](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725)
* [mev on eth2 talk by vitalik](https://www.youtube.com/watch?v=OD54WfVuDWw&list=PLRHMe0bxkuel3w3C7P_WVvp9ShLi3HKRI&index=30)
* [updates on pbs video by barnabe monnot](https://archive.devcon.org/archive/watch/6/updates-on-proposer-builder-separation/?tab=YouTube)
* [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs/tree/dev/specs)
* [Increasing censorship resistance of transactions under proposer/builder separation (PBS), by Vitalik et al](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
* [Weak Subjectivity in Eth2.0](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2)
* [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs)
* [order flow, auctions, and centralization (flashbots)](https://collective.flashbots.net/t/order-flow-auctions-and-centralisation-i-a-warning/258)

View file

@ -0,0 +1,40 @@
## block builders on ethereum
<br>
### tl; dr
<br>
* block builders have the same 3 sources of tx as validators did before the merge. they can:
1. act as searchers and include their own MEV-extracting transactions.
2. include txs submitted to them privately, including those submitted by external searchers (through a "bribe" through either coinbase payments or `txsFees`).
3. include pending tx broadcasted in the public mempool
* `blockValue` = `txFees` + MEV
* builders will aggregate txs from users, MEV searchers, and own private order flow to make the highest value blocks possible
* builders having its blocks included consistently incentivizes more private order flow (searchers want their tx included)
* builder can be selling future blockspace upfront so market makers or protocols can secure block space for their transactions or users
<br>
<img width="530" src="https://user-images.githubusercontent.com/1130416/217417346-50916961-aaa2-49ef-ad10-2f623a959fa6.png">
<br>
----
### resources
<br>
* [builder specs, by the ef](https://github.com/ethereum/builder-specs)
* [flashbots builder](https://github.com/flashbots/builder)
* [etherscan blocks](https://etherscan.io/blocks), [mev blocks](https://etherscan.io/blocks/label/mev-block), and [mev builders](https://etherscan.io/accounts/label/mev-builder)
* [builder69.io endpoint for searchers (bundle/tx)](https://builder0x69.io)
* [mev-rs - gateway to a network of block builders](https://github.com/ralexstokes/mev-rs)
* [mev order flow, the king of block builders](https://coinyuppie.com/mev-order-flow-the-king-of-block-builders/)
* [manifold finance](https://www.manifoldfinance.com/)
* [block builder decentralization is coming, but maybe not so soon, by ballsyalchemist](https://bittokoin.substack.com/p/block-builder-decentralization-is)

View file

@ -0,0 +1,25 @@
## blockspace derivatives
<br>
### risks examples
#### nft launches
* a big project could increase demand for blockspace, so gas prices would spike during these mints. actors could buy a lot of blockspace derivatives for said date.
#### block size manipulation
* if a block is larger than the target block size, the base fee increases. a block builder can manipulate the size of the block to increase/decrease the base fee in the next block.
<br>
### resources
- [ethereum blockspace by paradigm](https://research.paradigm.xyz/ethereum-blockspace)
- [ethereum blockspace by alkimiya](https://www.aniccaresearch.tech/blog/ethereum-blockspace-who-gets-what-and-why)
- [structuring blockspace derivatives by julian ma](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/WKa3GFC03uY34d2MufTyD0c595xVRUEZi9RNG-dHNKs)
- [slot space vc. blockspace](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/CPYI91s98cp9zKFkanKs_qotYzw09kWvouaAa9GXBrQ)
- [builders buying empty blocks and relaying through flashbots](https://twitter.com/MevRefund/status/1573416023998578703)

View file

@ -0,0 +1,150 @@
## mev and eip-1559
### tl; dr
<br>
<img width="746" alt="Screen Shot 2022-12-21 at 8 53 03 PM" src="https://user-images.githubusercontent.com/1130416/209059634-7d8384b2-4198-4406-8880-3b35a4d54d4d.png">
<br>
- The incorporation of EIP-1559 in the London hardfork brought a major restructuring of the Ethereum fee mechanism, aiming to allow for easier
fee estimation by users and consolidate ETH as the base currency of the network by burning part of the transaction fees.
- EIP-1559 changed this fee market. Users now pay a fee consisting of a base fee, which is burned, and a tip, that goes to the block builder.
The maximum block size doubled to 30 million gas units, however, the target block size is half of that. If there are few users willing to pay the base fee and the block size is below the target, the base fee decreases. Similarly, if the block size is above the target, the base fee increases.
- In other words, under the new fee mechanism, instead of choosing a gas price for their transactions, users set a "priority fee" for miners to incentivize inclusion, alongside a "max fee", stating the absolute maximum price that they are willing to pay. The protocol now sets a per-block "basefee", computed programmatically from the amount of gas used in the block immediately before, in a negative feedback loop meant for block sizes to stabilize around a target size $s_0$ (initially equal to the maximum current block size).
- Valid transactions pay a gas price equal to the basefee plus the prioirity fee (only up to the max fee needed in case of sudden basefee increases). The prioirity fee goes to the miner, and, crucially, the basefee is burnt.
- Implications for MEV-related infrastructure: eliminate the possibility of zero-Gwei transactions, which are presently used for frontrunning
protection in some DEXes, where miner fees are taken directly from the transferred tokens.
- eip1559 is kind of a perpetual second-price auction. The basefee floats to price out exactly enough users such that the remaining ones fill the block to capacity. Sometimes it increases (as in English auctions), when the demand is higher than the supply, and sometimes it decreases (as in Dutch auctions), when the demand is lower than the supply.
<br>
<img width="612" alt="Screen Shot 2022-11-17 at 1 18 14 PM" src="https://user-images.githubusercontent.com/1130416/202561827-69afafa9-7f44-438b-babf-f823b7ac7ee1.png">
<br>
---
### dune queries
#### eip-1559 adoption
```
SELECT
DATE_TRUNC('month',block_time) AS month,
COUNT(*) FILTER ( WHERE `type` = 'DynamicFee') / COUNT(*) AS eip1559_tx,
COUNT(*) FILTER ( WHERE `type` = 'Legacy' ) / COUNT(*) AS legacy_tx,
COUNT(*) FILTER ( WHERE `type` NOT IN ('DynamicFee', 'Legacy') ) / COUNT(*) AS other_tx
FROM
ethereum.transactions
WHERE
block_number >= 12965000 --London upgrade block number
GROUP BY
month
```
<br>
#### split base fee / priority fee
```
SELECT
DATE_TRUNC('month', tx.block_time) AS month,
SUM(
CASE
WHEN tx.block_number < 12965000 THEN tx.gas_used * tx.gas_price/1e18
ELSE tx.gas_used * tx.priority_fee_per_gas/1e18
END
) as fees_miner_eth,
SUM(tx.gas_used * blk.base_fee_per_gas/1e18) AS fees_burnt_eth
FROM
ethereum.transactions tx
INNER JOIN ethereum.blocks blk ON tx.block_number = blk.number
WHERE
tx.block_time >= '2021-01-01'
GROUP BY
month;
```
<br>
#### price impact
```
SELECT
DATE_TRUNC('month', block_time) as month,
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY gas_price)/1e9 as median_gas_price
FROM
ethereum.transactions
WHERE
DATE(block_time)>= '2021-01-01'
GROUP BY
month
````
<br>
#### gas volatility
```
WITH blocks_iqr_gas AS (
SELECT
block_number,
((PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY gas_price)) - (PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY gas_price))) / PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY gas_price) AS iqr_gas
FROM ethereum.transactions
WHERE DATE(block_time)>= '2021-01-01'
GROUP BY block_number
)
--Compute the median of IQR for every month
SELECT DATE_TRUNC('month', time) AS month,
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY iqr_gas) AS median_gas_volatility
FROM blocks_iqr_gas blk_iqr
INNER JOIN ethereum.blocks blk
ON blk_iqr.block_number = blk.number
GROUP BY month;
```
<br>
#### tx gas limits (looking at traces)
```
SELECT
block_number,
tx_hash,
error,
'https://etherscan.io/tx/' || tx_hash AS etherscan_tx_link,
'https://etherscan.io/vmtrace?txhash=' || tx_hash || '&type=gethtrace2' AS etherscan_trace_link
FROM
ethereum.traces
WHERE
error = "Out of gas"
AND block_time > NOW() - INTERVAL '1 hour'
ORDER BY block_time DESC
LIMIT 10;
```
<br>
----
### resources
- [eip-1559 dune board](https://dune.com/barnabe/EIP1559)
- [structuring blockspace derivatives by julian ma](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/WKa3GFC03uY34d2MufTyD0c595xVRUEZi9RNG-dHNKs)
- [agent-based simulation environment for EIP 1559.](https://github.com/ethereum/abm1559)

View file

@ -0,0 +1,150 @@
## 🍟 basic evm knowledge
<br>
### tl;dr
* the ethereum virtual machine (evm) is a stacked-based computer.
* a virtual machine is a program built into software (ethereum clients, e.g. geth) that recreates a computer's functionality.
* to become a validator and produce blocks, running the evm is a mean to compute state transitions.
* tokens sent to a new account means that the ethereum's map of who owns what needs to change. this is done by the validators taking input/txs, running the instructions in the evm, and then printing the output in a block header.
* an ethereum client contains:
* the mempool (location of signed txs ready to get included in a block),
* JSON-RPC api (which provides a data structure for processing requests to read/write data to ethereum),
* a client process (which sends txs from the mempool to the evm).
<br>
---
### merkle patricia trie
* one of the critical functions of the evm is to store the "state" of all accounts and what information those accounts store.
* the evm stores state according to a data structure called "merkle patricia trie", which contains all the key:pairs of all addresses on ethereum. the keys correspond to both public keys and smart contracts addresses, and the values represent the current state of those addresses.
* the value/state of each address is itself an encoding of the hash of the address's respective code, a hash of the data stored by the account, its balance, and the number of txs it's carried out (represented as a nonce).
* a merkle patricia trie is used to store this data because it makes it easy to perform hashes of all the key-value pairs to eventually get to a singular "merkle root hash" of the state of who owns what (a required field in the block header of a validator's proposed block).
* because of how the hashes work, even a minute change in the blockchain state will result in a completely different root hash.
* the reason for mandating validators to include this root hash in a block header is that it significantly enhances the security of the network. this is because it enables light nodes (which don't have the space to store this merkle patricia trie) to verify the legitimacy of the block that a validator is attempting to proliferate.
* a light node can compute a "merkle proof" with the root hash, account key, and balance value of the proposing full node, and compare that to a merkle proof of its own address & balance. there would be no match in the merkle proofs if there were any incorrect data.
<br>
---
### accounts
* an Ethereum account contains four fields:
* the nonce: a counter used to make sure each transaction can only be processed once
* the account's current ether balance
* the account's contract code
* the account's storage
* there are two types of accounts: externally owned accounts (controlled by private keys) and contract accounts (controlled by their contract code).
<br>
---
### txs
* a transaction refers to the signed data package that stores a message to be sent from an externally owned account.
* It contains:
* the recipient of the message
* a signature identifying the sender
* the amount of ether to transfer from the sender to the recipient
* an optional data field
* STARTGAS, representing the maximum number of computation steps the transaction is allowed to take
* GASPRICE, representing the fee the sender pays per computation step
* each tx has an intrinsic cost of 21000 gas, and creating a contract costs 32000 more gas.
<br>
---
### message
* a message is like a transaction, except it is produced by a contract and not an external actor. a message is produced when a contract currently executing code executes the CALL opcode.
* contracts can send "messages" to other contracts, which are virtual objects that are never serialized and exist only in the Ethereum execution environment. It contains:
* the sender of the message (implicit)
* the recipient of the message
* the amount of ether to transfer alongside the message
* an optional data field
* STARTGAS
<br>
---
### code execution
* The existence of a Turing-complete programming language means that arbitrary contracts can be created for any transaction type or application.
* The operations have access to three types of space in which to store data:
* the stack, a last-in-first-out container to which values can be pushed and popped
* memory, an infinitely expandable byte array
* contract's long-term storage, a key/value store (persist long term)
* the code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as the EVM.
* when a user is submitting a signed tx through a wallet, the tx data is compiled into bytecode and sent to a node using JSON-RPC api.
* bytecode is the low-level language that the evm reads to compute state transitions. bytecode appears as a hex encoding of a string of binary. collections of these bytes represent specific operations, known as opcodes that the evm will perform.
* the reason why opcodes are important is that when computed, they enable the evm to find the output of the state transition requested by the tx.
* when sent to the mempool, the bytecode is passed as an argument in a tx broadcast to a node's mempool using JSON-RPC api. after this, the tx sits in the mempool with other unconfirmed txs ready to be included in a block by a validator.
* when a validator picks the txs it wants to include in a block, it will have to compute state transitions as defined by the operations/opcodes indicated by each txs respective bytecode (through the evm).
<br>
---
### memory
* when the evm executes a smart contract, a context is created for it (with several memory regions).
* storing the state of all accounts is data that the evm stores permanently, but the evm uses temporary memory to execute opcodes. there are two types of temporary memory during opcode execution: stack and memory.
* memory is an array of data that can be used to store information temporarily to pass through data required to compute the instructions on top of the stack (it only exists during the smart contract execution, and it's accessed with a byte offset).
* the stack is the data area where the computations as defined by opcodes are performed. it's a list of 32-byte elements.
* when txs are accessed by the evm through the mempool using the client process, the evm takes the instructions in the sequence specified by the bytecode and the bytecode gets separated into their respective opcodes.
* the stack follows the instructions at the top of the stack and utilizes data/variables moved to memory during the process to compute the instructions on top of the stack. the evm also requires information about the state it fetched from storage to run the opcodes.
* all instructions interact with the stack, but it can be directly manipulated with instructions like PUSH1, POP, DUP1, or SWAP1.
<br>
---
### opcodes
* a smart contract is a set of instructions. an instruction is assigned a value between 0 and 255 (FF in hex), called opcode, which is a text representation.
* each opcode has a specific cost. there are two part for their gas cost: 1) static cost, for running the opcode, and 2) dynamic cost, depending on factors during execution.
* when all opcodes have been run, this implies that any output about a change in state will be loaded to permanent storage by the stack.
* once each opcode is run, the amount of gas spent in executing is subtracted from the available gas specified when the user originally submitted the tx.
* if insufficient gas was sent to cover the cost of running the opcodes, the validator does not include the tx in the block but the user doesn't get refunded because the validator has already incurred the cost to run the computation.
* once this process has been completed for all txs in the mempool that the validator wants to include in the block, the validator can compute the root hash of the new state and include it in the block header.
<br>
----
### the calldata
* the calldata region is the data that is sent with a transaction.
* on contract creation, it's the constructor code.
* this region is immutable and can be read with CALLDATALOAD, CALLDATASIZE, and CALLDATACOPY.
* calldata costs 4 gas per byte equal to 0, and 16 for others (paid before the opcode is executed).
<br>
---
### resources
* [the ethereum book on the evm](https://github.com/ethereumbook/ethereumbook/blob/develop/13evm.asciidoc)
* [0xFunk thread](https://twitter.com/0xFunk/status/1533667533164662785)

View file

@ -0,0 +1,108 @@
# [experiment] deploy a private ethereum blockchain on kubernetes
<br>
### tl;dr
<br>
* deploy it with your own [geth](https://geth.ethereum.org/) and a customized genesis file and all.
* geth implements [Clique](https://eips.ethereum.org/EIPS/eip-225#:~:text=Clique%20is%20a%20proof%2Dof,any%20client%20with%20minimal%20effort.), a proof-of-authority mechanism to reach consensus. Moreover, a number of accounts a defined to produce new blocks in the chain.
* a custom Ethereum testnet contains three components:
* a custom [genesis file](/genesis.json
* a custom data directory, which we define with `GETH_DATADIR`
* a custom `NetworkID` , which we set `137`
<br>
---
<br>
### documentation for this work
<br>
* [genesis block explanation](https://github.com/bt3gl-labs/1337_mev_toolkit/blob/main/geth_and_k8s/genesis_block_explanation.md)
* [deployment on gcp and docker](https://github.com/bt3gl-labs/1337_mev_toolkit/blob/main/geth_and_k8s/deployment_gcp_docker.md)
* [deployment of geth in gcp + kubernetex](https://github.com/bt3gl-labs/1337_mev_toolkit/blob/main/geth_and_k8s/deployment_gcp_k8s.md)
* [running a node in ethereum with geth](https://github.com/bt3gl-labs/1337_mev_toolkit/blob/main/geth_and_k8s/running-a-node-geth.md)
* [geth creation commands](https://github.com/bt3gl-labs/1337_mev_toolkit/blob/main/geth_and_k8s/geth_creation_commands.md)
<br>
---
<br>
### nodes
<br>
* running nodes are responsible for the following tasks:
- store blockchain data,
- participates in block validation (verifying blocks and states),
- serve the network and provides data on request.
* interacting with the client:
<br>
##### getting total coinbase
```bash
web3.fromWei(eth.getBalance(eth.coinbase), "ether")
```
##### getting a balance from an account
```bash
web3.fromWei(eth.getBalance("2ee8D80de1c389f1254e94bc44D2d1Bc391eD402"), "ether")
```
##### txpool api
* access to several non-standard RPC methods to inspect the contents of the transaction pool containing all the currently pending transactions as well as the ones queued for future processing:
```bash
txpool
```
##### useful checks
```bash
admin.nodeInfo
```
##### setting this chain on metamask
* click a `custom RPC` network and add:
```bash
Network Name: "<project name>"
New RPC URL: localhost
Chain ID: 137
```
<br>
---
<br>
### references
* [geth commands](https://geth.ethereum.org/docs/interface/command-line-options)

View file

@ -0,0 +1,205 @@
# Deployment of geth in GCP + docker
In this deployment, we use **Container-Optimized OS** to permit the deployment of a Docker image to a **Google Compute Engine VM**.
This is the simplest way to run the `ethereum/client-go` image. This will install `geth`, the **Golang CLI Ethereum client** for running a full Ethereum node and interacting with Ethereum networks.
---
### Installing
Install [google cloud sdk](https://cloud.google.com/sdk/docs/quickstart) and configure it with:
```
gcloud init
gcloud auth login
gcloud config set project <project name>
```
### Create the instance
```
gcloud beta compute instances create-with-container <docker container alias> \
--boot-disk-size=500GB \
--boot-disk-type=pd-ssd \
--container-image=ethereum/client-go \
--container-arg="--rpc" \
--container-arg="--rpcaddr=0.0.0.0" \
--container-restart-policy=always \
--container-mount-host-path=\
mount-path=/root,\
host-path=/tmp/client-go,\
mode=rw \
--image-family=cos-stable \
--image-project=cos-cloud \
--zone=<which zone?> \
--project=<project name>
```
The instance should be available at the project's [GCP dashboard](https://console.cloud.google.com/compute/instances).
`Geth` needs to have a special CORS setting enabled to allow MetaMask to connect to it by default, so try starting it with this command:
```
geth --rpc --rpccorsdomain="chrome-extension://<hash>"
```
### Start `konlet-startup`
`konlet-startup` is the `systemd` service that corresponds to the docker image deployment in the **Container-Optimized OS**.
Run:
```
gcloud compute ssh <docker container alias> \
--command="sudo journalctl --unit=konlet-startup --follow" \
--project=<project name>
```
### Confirm that the container is running
```
gcloud compute ssh <docker container alias> \
--command="docker ps --format='[{{.ID}}] {{.Names}}: {{.Status}}'" \
--project=<project name>
```
### SSH and port-forwarding
```
gcloud compute ssh <docker container alias> \
--ssh-flag="-L 8545:localhost:8545" \
--project=<project name>
```
Success looks like:
```
########################[ Welcome ]########################
# You have logged in to the guest OS. #
# To access your containers use 'docker attach' command #
###########################################################
<user>@<project name> >
```
### Additional configuration for the intance
* [Alocate a static IP](https://console.cloud.google.com/networking/addresses/).
* [Prevent deletion](https://console.cloud.google.com/compute/instancesDetail/).
* Configure CORS [here]().
----
## Creating the Testnet
The command to create a testnet with `geth` is:
```
geth init --datadir data ./genesis.json
```
and then starting the node:
```
geth --datadir data --networkid NetworkID
```
`NetworkID` helps ensure the privacy of your network. You can use any number and peers joining the network must use the same number.
### Starting the genesis block
Inside the instance, create the `genesis.json` file:
```
vim ~/genesis.json
```
with
```
{
"config": {
"chainId": 137,
"homesteadBlock": 0,
"eip150Block": 0,
"eip155Block": 0,
"eip158Block": 0,
"byzantiumBlock": 0,
"constantinopleBlock": 0,
"petersburgBlock": 0
},
"difficulty": "0x400",
"gasLimit":"0x2100000",
"alloc": {
"3282791d6fd713f1e94f4bfd565eaa78b3a0599d": {
"balance": "1337000000000000000000"
}
}
}
```
Start the testnet with:
```
geth --identity <project name> --nodiscover --networkid 137 --datadir ~/data init ~/genesis.json
```
Where `geth` flags are:
* `--datadir` indicates the data for our local testnet.
* `--nodiscover`, `--maxpeers 0`, `--rpc`, `--rpcapi` make sure the network is private.
---
## Interacting with the testnet
### Connecting to a member node
From another terminal, run:
```
docker run \
--rm \
--interactive \
--net=host \
--tty \
ethereum/client-go \
attach http://localhost:8545
```
or
```
geth attach http://localhost:8545
```
Success looks like:
```
Welcome to the Geth JavaScript console!
>
```
### Monitoring
* GCP logs can be found [here](https://console.cloud.google.com/logs).
* To look at the output from the tesnet run:
```
FILTER="resource.type=\"global\" "\
"logName=\"projects/<project-name>/logs/gcplogs-docker-driver\" "
gcloud logging read "${FILTER}" \
--project=<project name> \
--format="value(jsonPayload.data)" \
--order=asc
```

View file

@ -0,0 +1,53 @@
# Deployment of geth in GCP + Kubernetes
## Deployment
```
NAMESPACE=ethereum
kubectl create namespace ${NAMESPACE}
kubectl apply --filename=deployment.yaml --namespace=${NAMESPACE}
```
## Accessing node without opening firewall
```
SERVICE=ethereum
NAMESPACE=ethereum
NODE=$(\
kubectl get nodes \
--output=jsonpath='{.items[0].metadata.name}')
PORT=$(\
kubectl get services/${SERVICE} \
--namespace=${NAMESPACE} \
--output=jsonpath='{.spec.ports[?(@.name=="default")].nodePort}')
echo ${PORT}
gcloud compute ssh <docker container alias> \
--ssh-flag="-L ${PORT}:localhost:${PORT}" \
--project=<project name>
```
## Member connecting
```
docker run \
--rm \
--interactive \
--tty \
--net=host \
ethereum/client-go attach http://localhost:${PORT}
```
### Dealing with secrets
```
kubectl create secret generic keystore \
--from-file=path/to/keystore \
--namespace=$NAMESPACE
```

View file

@ -0,0 +1,69 @@
#!/usr/bin/env bash
set -ex
GETH_DATADIR=${GETH_DATADIR:-"/data"}
geth_init() {
ls -al "$GETH_DATADIR"
if [[ -d "$GETH_DATADIR/keystore" ]]; then
echo "Chain already initialized"
return 0
fi
echo "Initializing using Genesis"
geth init --datadir "$GETH_DATADIR" /genesis.json
}
geth_custom_start() {
echo "Starting node with custom arguments $@"
exec geth $@
}
geth_normal_start() {
echo "Starting node"
local identity=${GETH_IDENTITY:-"<docker container alias>"}
local http_corsdomain=${GETH_HTTP_CORSDOMAIN:-"http://localhost:3000"}
local http_vhosts=${GETH_HTTP_VHOSTS:-"localhost"}
local networkid=${GETH_NETWORKID:-"137"}
local enable_mining=${ENABLING_MINING:-"YES"}
local mining_args=""
if [[ "$enable_mining" == "YES" ]]; then
local miner_etherbase=${GETH_MINER_ETHERBASE:-"<add etherbase>"}
local miner_threads=${GETH_MINER_THREADS:-1}
mining_args="$mining_args --mine"
mining_args="$mining_args --miner.threads $miner_threads"
mining_args="$mining_args --miner.etherbase $miner_etherbase"
fi
exec geth \
--identity "$identity" \
--nodiscover \
--http \
--http.addr 0.0.0.0 \
--http.corsdomain "$http_corsdomain" \
--http.vhosts "$http_vhosts" \
--networkid "$networkid" \
--datadir "$GETH_DATADIR" \
$mining_args \
"$@"
}
main() {
local should_initialize=${SHOULD_INITIALIZE:-"YES"}
local custom_start=${CUSTOM_START:-"NO"}
if [[ "$should_initialize" == "YES" ]]; then
geth_init
fi
if [[ "$custom_start" == "YES" ]]; then
geth_custom_start "$@"
else
geth_normal_start "$@"
fi
}
main "$@"

View file

@ -0,0 +1,8 @@
FROM ethereum/client-go:stable
RUN apk add --no-cache bash
COPY entrypoint.sh /entrypoint.sh
COPY genesis.json /genesis.json
ENTRYPOINT /entrypoint.sh

View file

@ -0,0 +1,29 @@
{
"config": {
"chainId": 137,
"homesteadBlock": 0,
"eip150Block": 0,
"eip155Block": 0,
"eip158Block": 0,
"byzantiumBlock": 0,
"constantinopleBlock": 0,
"petersburgBlock": 0
},
"difficulty": "0x400",
"gasLimit":"0x2100000",
"nonce": "0x000000000fab0042",
"alloc": {
"3282791d6fd713f1e94f4bfd565eaa78b3a0599d": {
"balance": "1337000000000000000000"
},
"64D2ea7000e831E03e6B930AC348fD90D4ACE2B8": {
"balance": "1337000000000000000000"
},
"2ee8D80de1c389f1254e94bc44D2d1Bc391eD402": {
"balance": "1337000000000000000000"
},
"Ac03BB73b6a9e108530AFf4Df5077c2B3D481e5A": {
"balance": "1337000000000000000000"
}
}
}

View file

@ -0,0 +1,30 @@
## What's the genesis block
The genesis block is a `JSON` file hardcoded into clients and Ethereum's consensus algorithm.
It's the start of the blockchain, the first block (`block 0`), and the only block that does not point to a predecessor block.
It ensures that no other node will agree unless they have the same genesis block.
---
#### Fields
* **chainId**: A unique identifier of the new private blockchain
* **mixhash**: A `256-bit` hash which proves, combined with the nonce, that a sufficient amount of computation has been carried out on this block (Proof-of-Work).
* **nonce**: A `64-bit hash`, which proves, combined with the mixhash, that a sufficient amount of computation has been carried out on this block (Proof-of-Work).
* **difficulty**: A value corresponding to the difficulty level applied during the nonce discovering of this block. The higher the difficulty, the statistically more calculations a miner must perform to discover a valid block.
* **alloc**: Allows defining a list of pre-filled wallets.
* **coinbase**: A `160-bit` address to which all rewards (in Ether) collected from the successful mining of the block have been transferred. This can be anything in the Genesis Block since the value is set by the setting of the Miner when a new Block is created.
* **timestamp**: A value equal to the reasonable output of Unix `time()` function at this block inception.
* **parentHash**: A `256-bit` hash of the entire parent block header (including its nonce and mixhash). Pointer to the parent block, thus effectively building the chain of blocks. In the case of the Genesis block, and only in this case, its 0.
* **gasLimit**: A scalar value equal to the current chain-wide limit of Gas expenditure per block. High in our case to avoid being limited by this threshold during tests.

View file

@ -0,0 +1,75 @@
# geth creation commands
### Create a miner account
This will generate a public/private key pair. By default, keys are stored inside, `<datadir>/keystore`. Everything `geth` persists gets written inside `<datadir>`.
The following command returns a private testnet address (which should be saved together with the password):
```
geth account new --datadir /path/to/data
```
### Start mining
With `NetworkID`:
```
geth --mine --rpc --networkid NetworkID --datadir /path/to/data
```
Start mining:
```
> miner.start()
```
To end mining, type:
```
> miner.stop()
```
### Pre-fund the account
Deploying contracts or making transactions requires test ether, which has no value and can be acquired for free from several "faucets".
The command `geth removedb` deletes the locally synced blockchain data of the public testnet (i.e., resyncs with the chain).
To add magic ether, remove the created blockchain database:
```
geth removedb --datadir /path/to/data
```
Modify `genesis.json` as necessary, including multiple accounts in the seed if wanted.
Finally, re-initialize the genesis block:
```
geth --identity <project name> --nodiscover --networkid 1337 --datadir /path/to/data init /path/to/genesis.json
```
### Create new accounts
```
geth --datadir . account new
```
### List accounts
```
geth --datadir . account list
```
### Connect to the testnet
```
geth attach
```
You will enter into the **Geth Javascript console**, where you can run JavaScript code.

View file

@ -0,0 +1,12 @@
---
apiVersion:
kind: Certificate
metadata:
labels:
env: staging
app:
runtime-component: web
spec:
dnsNames:
-
secretName:

View file

@ -0,0 +1,114 @@
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
name: web
env: staging
app:
runtime-component: web
annotations:
spec:
replicas: 1
selector:
matchLabels:
name: web
template:
metadata:
labels:
name: web
env: staging
app:
annotations:
seccomp.security.alpha.kubernetes.io/pod: runtime/default
spec:
automountServiceAccountToken: true
containers:
- name: web
image:
ports:
- name: http
containerPort: 8545
envFrom:
- configMapRef:
name: application-state
env:
- name: SHOULD_INITIALIZE
value: "YES"
- name: ENABLING_MINING
value: "YES"
- name: ENV
value: staging
- name: APP_ENV
value: staging
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: NODE_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: TRACE_PROXY_ADDR
value: http://$(NODE_IP):8096/
- name: STATSD_ADDR
value: 127.0.0.1:8125
- name: STATSD_IMPLEMENTATION
value: datadog
- name: IDENTITY_CLIENT_ID
valueFrom:
secretKeyRef:
name: identity-config
key: clientId
optional: true
- name: IDENTITY_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: identity-config
key: clientSecret
optional: true
resources:
limits:
cpu: 2000m
memory: 1Gi
requests:
cpu: 1500m
memory: 512Mi
volumeMounts:
- name: ejson-keys
readOnly: true
mountPath: /key
- name: data
mountPath: /data
readinessProbe:
httpGet:
port: 8545
httpHeaders:
- name: X-Forwarded-Proto
value: https
path: /
initialDelaySeconds: 20
timeoutSeconds: 3
securityContext:
allowPrivilegeEscalation: false
capabilities:
add:
- CHOWN
- DAC_OVERRIDE
- KILL
- SETGID
- SETUID
drop:
- ALL
privileged: false
volumes:
- name: ejson-keys
secret:
secretName: ejson-keys
- name: data
persistentVolumeClaim:
claimName: web
strategy:
type: Recreate
progressDeadlineSeconds: 120

View file

@ -0,0 +1,24 @@
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
labels:
name: web
env: staging
app:
runtime-component: web
annotations:
kubernetes.io/ingress.class: nginx
kubernetes.io/tls-acme: "false"
spec:
rules:
- host:
http:
paths:
- backend:
serviceName: web
servicePort: 80
tls:
- hosts:
-
secretName:

View file

@ -0,0 +1,20 @@
---
kind: RuntimeManifest
apiVersion:
metadata:
name:
runtimeInfo:
appName:
env: staging
appImage:
domains:
-
defaultBaseSource:
components:
- name: web
baseSource:
resources:
- base: deployment.yaml
- base: service.yaml
- base: certificate.yaml
- base: ingress.yaml

View file

@ -0,0 +1,18 @@
---
apiVersion: v1
kind: Service
metadata:
labels:
name: web
env: staging
app:
runtime-component: web
spec:
selector:
name: web
env: staging
app:
ports:
- name: http
port: 80
targetPort: 8545

View file

@ -0,0 +1,43 @@
## Running a node in Ethereum with `geth`
```
geth -help
```
```
COMMANDS:
account Manage accounts
attach Start an interactive JavaScript environment (connect to node)
console Start an interactive JavaScript environment
db Low level database operations
dump Dump a specific block from storage
dumpconfig Show configuration values
dumpgenesis Dumps genesis block JSON configuration to stdout
export Export blockchain into file
export-preimages Export the preimage database into an RLP stream
import Import a blockchain file
import-preimages Import the preimage database from an RLP stream
init Bootstrap and initialize a new genesis block
js Execute the specified JavaScript files
license Display license information
makecache Generate ethash verification cache (for testing)
makedag Generate ethash mining DAG (for testing)
removedb Remove blockchain and state databases
show-deprecated-flags Show flags that have been deprecated
snapshot A set of commands based on the snapshot
version Print version numbers
version-check Checks (online) whether the current version suffers from any known security vulnerabilities
wallet Manage Ethereum presale wallets
```
Advanced options are:
```
ETHEREUM OPTIONS
LIGHT CLIENT OPTIONS
DEVELOPER CHAIN OPTIONS
ETHASH OPTIONS
```

View file

@ -0,0 +1,17 @@
#!/usr/bin/env bash
set -ex
PORT=${PORT:-18545}
echo "Building local blockchain container"
docker build -t <docker container alias> .
echo "Starting blockchain network on port $PORT (use rpc URL http://localhost:$PORT)"
docker run -it --rm \
-v $(pwd)/genesis.json:/genesis.json \
-v $(pwd)/data:/data \
-p $PORT:8545 \
<docker container alias>

View file

@ -0,0 +1,69 @@
#!/usr/bin/env bash
set -ex
GETH_DATADIR=${GETH_DATADIR:-"/data"}
geth_init() {
ls -al "$GETH_DATADIR"
if [[ -d "$GETH_DATADIR/keystore" ]]; then
echo "Chain already initialized"
return 0
fi
echo "Initializing using Genesis"
geth init --datadir "$GETH_DATADIR" /genesis.json
}
geth_custom_start() {
echo "Starting node with custom arguments $@"
exec geth $@
}
geth_normal_start() {
echo "Starting node"
local identity=${GETH_IDENTITY:-"<docker container alias>"}
local http_corsdomain=${GETH_HTTP_CORSDOMAIN:-"http://localhost:3000"}
local http_vhosts=${GETH_HTTP_VHOSTS:-"localhost"}
local networkid=${GETH_NETWORKID:-"137"}
local enable_mining=${ENABLING_MINING:-"YES"}
local mining_args=""
if [[ "$enable_mining" == "YES" ]]; then
local miner_etherbase=${GETH_MINER_ETHERBASE:-"<add etherbase>"}
local miner_threads=${GETH_MINER_THREADS:-1}
mining_args="$mining_args --mine"
mining_args="$mining_args --miner.threads $miner_threads"
mining_args="$mining_args --miner.etherbase $miner_etherbase"
fi
exec geth \
--identity "$identity" \
--nodiscover \
--http \
--http.addr 0.0.0.0 \
--http.corsdomain "$http_corsdomain" \
--http.vhosts "$http_vhosts" \
--networkid "$networkid" \
--datadir "$GETH_DATADIR" \
$mining_args \
"$@"
}
main() {
local should_initialize=${SHOULD_INITIALIZE:-"YES"}
local custom_start=${CUSTOM_START:-"NO"}
if [[ "$should_initialize" == "YES" ]]; then
geth_init
fi
if [[ "$custom_start" == "YES" ]]; then
geth_custom_start "$@"
else
geth_normal_start "$@"
fi
}
main "$@"

View file

@ -0,0 +1,8 @@
FROM ethereum/client-go:stable
RUN apk add --no-cache bash
COPY entrypoint.sh /entrypoint.sh
COPY genesis.json /genesis.json
ENTRYPOINT /entrypoint.sh

View file

@ -0,0 +1,29 @@
{
"config": {
"chainId": 137,
"homesteadBlock": 0,
"eip150Block": 0,
"eip155Block": 0,
"eip158Block": 0,
"byzantiumBlock": 0,
"constantinopleBlock": 0,
"petersburgBlock": 0
},
"difficulty": "0x400",
"gasLimit":"0x2100000",
"nonce": "0x000000000fab0042",
"alloc": {
"3282791d6fd713f1e94f4bfd565eaa78b3a0599d": {
"balance": "1337000000000000000000"
},
"64D2ea7000e831E03e6B930AC348fD90D4ACE2B8": {
"balance": "1337000000000000000000"
},
"2ee8D80de1c389f1254e94bc44D2d1Bc391eD402": {
"balance": "1337000000000000000000"
},
"Ac03BB73b6a9e108530AFf4Df5077c2B3D481e5A": {
"balance": "1337000000000000000000"
}
}
}

View file

@ -0,0 +1,68 @@
### terminology
<br>
* **attestation**: at designated times, each validator is responsible for publishing different attestations that formally declare this validator's view of the chain, including the last finalized checkpoint and the current head of the chain.
* **Block builder**
The agent responsible for assembling the potential contents of a block (i.e. the set of transactions that makes up the “payload” of a block). In Proof of Work Ethereum its the miner. In Proof of Stake Ethereum its the validator, but this activity can separated from the validator via PBS, in which case builders need to submit bids for blocks to be included to the block proposer for inclusion.
* **Block proposer**
The agent responsible for proposing new blocks in a blockchain. In Proof of Work Ethereum its the miner. In Proof of Stake Ethereum its the validator.
* **block time**: the time interval between blocks being added to the blockchain.
* **Node Operator**
An organization/entity/person that operates validators.
* **PBS**
Proposer Builder Separation, see: State of research: increasing censorship resistance of transactions under proposer/builder separation (PBS).
* **Staker**: A user/organization/etc. which holds (w)stETH
* `feeRecipient`: field set by the block builder in the block header (coinbase address)
* payment methods on Ethereum:
- `base_fee`: amount defined by the protocol, always paid from user -> network
- `priority_fee`: amount defined by the user as `maxPriorityFeePerGas`, paid from user -> coinbase address
- `block.coinbase transfer`: the EVM has an opcode which allows end user to send fund directly to the coinbase address (same recipient as `priority_fee`
- `regular transfer`: a transaction created to send eth to other account
* **LMD-GHOST**: latest message drive greediest heaviest observed subtree, the fork choice rule determining which block is viewed as the current chain head.
* **Casper-FFG**: proof-of-stake consensus protocol used in conjunction with the LMD-GHOST fork choice algorithm to allow consensus clients to agree on the head of the Beacon Chain.
* **Gasper**: Ethereums PoS implementation, a combination of the LMD-GHOST fork choice rule, Casper FFG, and the specific reward/penalty scheme.
* **RANDAO**: random number generation scheme used to select block proposers, sort validators into committees, etc.
* **BLS**: cryptographic signature scheme used for validator attestations.
* **inactivity leak**: validators which dont submit attestations are penalized if the chain stops finalizing.
* **slashing**: validators which maliciously propose or attest to multiple blocks at the same height have their stake reduced.
* **proposer boost**: a modification to LMD-GHOST giving additional weight to blocks proposed earlier in the slot to defend against avalanche attacks, see an explanation of a 7-block reorg in the beacon chain while this update was being rolled out.
* **distributed hash table (DHT)**: data structure containing (key, value) pairs used by Ethereum nodes to identify peers to connect to and determine which protocols to use to communicate.
* **committee**: group of at least 128 validators assigned to validate blocks in each slot. One of the validators in the committee is the aggregator.
* **slots**: a time period of 12 seconds in which a randomly chosen validator has time to proposa a block. 32 seconds = 1 epoch.
* **epoch**: represents 32 slots and takes ~6.4 minutes.
* **deposit contract**: the gateway to ethereum 2.0. It accepts any transaction with a minumum amount of 1 ETH and a valid input data.
* **input data**: also called deposit data, is a user generated, 842 long sequence of characters. it represents the validator pub key and the withdrawal pub key, which were signed with by the validator priv key. the input data needs to be added to the transaction to the deposit contract to be identified by the beacon-chain.
* **unique index**: every validator receives its unique index.
* **finality**: a transaction has "finality" when it's part of a block that can't change without a significant amount of ETH getting burned (this is managed using "checkpoint" blocks).
<br>

View file

@ -0,0 +1,44 @@
## Consensus mechanisms in PoS in Ethereum
>Proof-of-Stake Ethereum features two consensus mechanisms running in parallel, FFG Casper and LMD GHOST.
<br>
### casper FFG
* responsible for providing economic finality to the chain.
* when a checkpoint block (the start of an epoch) accumulates enough target votes, it becomes justified. When a recently justified source is used to justify a target checkpoint, the target checkpoint is justified and the source becomes finalised. no conflicting checkpoint block can be also finalised without at least 1/3 of the active stake getting slashed. there can be no re-org of the finalised chain without a massive loss of ETH by some party.
<br>
### LMD GHOST
* provide a dynamically available ledger - grow the chain while finalisation runs. headers in this chain accumulate weight by the head vote from attesters. the weight is used to figure out which branch the validator should follows if a fork happens.
<br>
### lexicon
* block trees: if ethereum gets out of sync (network latency, deliberate attack, etc.), the blockchain can quickly become a block tree. validators need a method to choose a branch and identigy a single canonical blockchain.
* checkpoint: a block every N blocks.
* root: always justified and finalized.
* supermajority link: ordered pair (x, y) of checkpoints where >2/3 of validators voted that y is the valid descedent from x.
* justification: a block is justified if there exists a supermajority link between it and a previously justified block.
* finalization: a block is finalized if it is justified and there is a supermajority link between the block and its direct descendent.
* when a new checkpoint is reached, each node broadcasts a vote to the network.
* votes contain a source (last justified) and a target (newlly added) checkpoint.
* validators must not publish two distinct votes such that 1) are the same height of the block tree, 2) overlapping votes.
* validators that break the casper voting rules are slashed: a portion of that validator stake is destroyed and the validator is removed from the network.
* validators have a responsibility to vote, failing to broadcast a vote will result in a small penalty, slowly draining the validators stake.
<br>
<br>
### resources
* [Validated, staking on eth2: #2 - Two ghosts in a trench coat](https://blog.ethereum.org/2020/02/12/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat)
* [Visualising the 7-block reorg on the Ethereum beacon chain](https://barnabe.substack.com/p/pos-ethereum-reorg?s=w)

View file

@ -0,0 +1,68 @@
## pbs tx and/or mev-boost relays
<br>
### tl; dr
* relays are a bundle propagation service that receives bundles from searchers, simulate each txs, and forwards them to block producers.
* validators can use relays to outsource their block production to entities specialized in extracting extra revenue.
<br>
### mainnet (mev-boost) relay list
* [flashbots]()
- The Flashbots team worked very closely with the Ethereum foundation as its founders were researchers who saw the threat that MEV posed to blockchains. Since then, theyve developed MEV-Geth and MEV-Boost to prevent the centralization of MEV searchers and validators.
* [blocknative](https://docs.blocknative.com/mev-relay-instructions-for-ethereum-validators)
- Blocknative provides one MEV relay, Dreamboat, that validators can connect to. This relay is open sourced and publicly available. Blocknative has APIs that allow developers and data analysts to identify proposer payloads, blocks received, and validator registration. Notably, Dreamboat is not a Flashbots Relay fork.
* [bloXroute MEV relay](https://bloxroute.max-profit.blxrbdn.com/)
- BloXroute has been known to provide traders with information services. Traders that receive information quickly have an edge in capturing the next opportunity. Imagine a block contains information that will change the price of an asset. If the trader sees this information, they can quickly calculate how this information will change the spread between two liquidity pools.
* [eden](https://relay.edennetwork.io/info)
- Eden is a permissioned system for block builders. They are accepting applications for block builders, but they also run their own. They capitalize on orderflow sent to their builder via their private RPC.
* [manifold]()
- Manifold has a focus on trade execution quality and end user settlement. They support blocks that are not OFAC compliant.
* [ultrasound money](https://relay.ultrasound.money/)
- not OFAC compliant
* [aestus](https://www.aestus.live/)
- not OFAC compliant
* [ethsaker relay list ](https://github.com/remyroy/ethstaker/blob/main/MEV-relay-list.md)
* [beaconcha.in relay list and stats](https://beaconcha.in/relays)
* [rated analytics on relays](https://www.rated.network/relays?network=mainnet)
<br>
### goerli relay list
* [flashbots](https://0xafa4c6985aa049fb79dd37010438cfebeb0f2bd42b115b89dd678dab0670c1de38da0c4e9138c9290a398ecd9a0b3110@builder-relay-goerli.flashbots.net)
* [bloxroute](https://0x821f2a65afb70e7f2e820a925a9b4c80a159620582c1766b1b09729fec178b11ea22abb3a51f07b288be815a1a2ff516@bloxroute.max-profit.builder.goerli.blxrbdn.com)
* [eden](https://0xaa1488eae4b06a1fff840a2b6db167afc520758dc2c8af0dfb57037954df3431b747e2f900fe8805f05d635e9a29717b@relay-goerli.edennetwork.io)
* [blocknative](https://0x8f7b17a74569b7a57e9bdafd2e159380759f5dc3ccbd4bf600414147e8c4e1dc6ebada83c0139ac15850eb6c975e82d0@builder-relay-goerli.blocknative.com)
* [manifold]( https://0x8a72a5ec3e2909fff931c8b42c9e0e6c6e660ac48a98016777fc63a73316b3ffb5c622495106277f8dbcc17a06e92ca3@goerli-relay.securerpc.com/)
<br>
### resources
* [everything mev-boost](https://github.com/MEV-WAIFU-LABS/mev_toolkit/blob/main/flashbots/mev-boost/README.md)
* [fb relay api](https://flashbots.notion.site/Relay-API-Spec-5fb0819366954962bc02e81cb33840f5)
* [uptime monitor for relays](https://mev-relays.beaconstate.info/)
* [mev relay ofac watch](https://www.mevwatch.info/)
* [mev-boost relay data](https://mevboost.pics/)
* [SushiGuardRouterV01 (with Manifold relay)](https://snapshot.org/#/sushigov.eth/proposal/bafkreigjjhjx2j2b526d3poeg23w2xan4rcgnzvcxinsssv7n37lu5p7s4)
* [relayscan.io](https://www.relayscan.io/)
<br>
##### on building a relay
* [fork mev-boost relay](https://github.com/flashbots/mev-boost-relay)
* [blocknative dreamboat](https://github.com/blocknative/dreamboat)
* [join lido call for relays](https://research.lido.fi/t/lido-on-ethereum-call-for-relay-providers/2844/10)
* [add label to beaconcha.in](https://beaconcha.in/relays)
* [join fb boost relays tg](https://t.me/+E-HTvTDIsdI3MjM1)
* [understanding mev-boost liveness risk by hasu](https://writings.flashbots.net/writings/understanding-mev-boost-liveness-risks/)
* [keeping relays honest](https://notes.ethereum.org/@yoav/BJeOQ8rI5)

View file

@ -0,0 +1,212 @@
## 🍕 more advanced notes on running validators
<br>
<br>
<p align="center">
<img width="547" alt="Screen Shot 2022-09-23 at 8 46 39 PM" width="70%" src="https://user-images.githubusercontent.com/1130416/192078957-0ed3b60b-7354-4e02-b439-332b92ff0613.png">
</p>
<br>
<br>
### tl;dr architecture
<br>
- the validator is responsible for creating a new block and sending it out to other nodes on the network.
- to participate as a validators, a user must deposit 32 ETH into the deposit contract and run 3 pieces of software:
- an execution client
- a consensus client
- the engine api
- once activated, validators receive new blocsk from peers (the txs delivered in the block are re-executed, and the block signature is checked).
- the validator then sends a vote (attestation) in favor of that block across the network.
- the timing of blocks is not determined by the mining difficult anymore, but it's fixed:
- slots (12 seconds)
- epochs (32 slots)
- in every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed.
- the first block in each epoch is a checkpoint.
<br>
----
### tl;dr block creation
<br>
1. execution clients gossip transactions over the execution-layer peer-to-peer network (encrypted communication)
2. the execution layer's networking protocols is divided into 2 stacks:
- the discovery stack: built on top of UDP and allows a new node to find peers to connect to
- he DevP2P stack: sits on top of TCP and enables nodes to exchange information
3. discovery of other nodes is boostrapped using a small set of bootnodes (nodes with addresses hardcoded into the client so they can be found easily)
4. a validator is selected to propose a block, and transactions from the node's local transaction pool is passed to consensus clients via a local RPC connection, which will be packaged into Beacon blocks
5. consensus clients use discv5 over UDP for finding peers.
6. consensus clients then gossip Beacon blocks across their p2p network
7. the process requires two separate p2p networks: one connecting execution clients for transaction gossip and one connecting consensus clients for block gossip
8. the libP2P stack supports all communications after discovery, clients can dial and listen on IPv4 and/or IPv6 as defined in their ENR.
<br>
<br>
<p align="center">
<img width="708" alt="Screen Shot 2022-09-24 at 12 10 38 AM" width="60%" src="https://user-images.githubusercontent.com/1130416/192085157-d3f76f7e-3241-481f-b1ae-6bdc644fa8c7.png">
</p>
<br>
<br>
---
### validator lifecycle
<br>
The sequence of states that a validator can exist in:
1. deposited: At least 32 ETH has been deposited to the deposit contract by the validator.
2. pending: the validator is in the activation queue waiting to be voted into the network by existing validators.
3. active: currently attesting and proposing blocks.
4. slashing: the validator has misbehaved and is being slashed.
5. exiting: the validator has been flagged for exiting the network, either voluntarily or because they have been ejected.
<br>
----
### network addresses
<br>
* three standardized formats that any Ethereum node can understand
##### multiaddr
* universal format designed for peer-to-peer networks
* for example, a classic IPv4 listing to TCP port 33000 `/ip4/192.168.22.27/tcp/33000`, plus an node id (a hash of the pub key)
<br>
##### enode
* identify an Ethereum node using a URL address format
<br>
##### ethereum node records (ENRs)
* allow greater informational exchange between nodes
* contains a signature, sequence number and fields detailing the identity scheme used to generate and validate signatures
* key-value pairs contain the node's IP address and information about the sub-protocols the node is able to use
* consensus clients use a specific ENR structure to identify boot nodes
<br>
---
### the JSON-RPC interface
<br>
* interface that allows us to write programs that use an Ethereum client as a gateway to an Ethereum network and blockchain.
* the RPC interface is offered as an HTTP service on port 8545. For security reasons it is restricted, by default, to only accept connections from localhost.
<br>
----
### setting a dedicated hardware
<br>
#### execution client
<br>
* [check estimate of the blockchain size](https://bitinfocharts.com/ethereum/).
* minimum specs:
- CPU with 4+ cores
- 16 GB+ RAM
- fast SSD with at least 1TB free space, up to 12TB+ (bottleneck for your hardware is mostly disk space.
- interent bandwith ~1.2-1.3 GB download and ~0.9-1 GB upload per hour.
<br>
#### consensus client
<br>
* ~200GB for beacon data.
<br>
#### engine api
<br>
* in order to connect a consensus client, the execution client must generate a jwtsecret:
```
openssl rand -hex 32 > jwtsecret
```
<br>
#### other considerations
<br>
* after downloading a client release and its signature, use some PGP to verify them.
* your router and firewall needs to accept connections on listening ports. By default Ethereum clients use a listener (TCP) port and a discovery (UDP) port, both on 30303 by default.
* execution clients offer RPC API endpoints that you can use to submit transactions, interact with or deploy smart contracts on Ethereum.
* the consensus clients all expose a Beacon API that can be used to check the status of the consensus client or download blocks and consensus data.
* a privacy-preserving way to set up a publicly reachable endpoint is to host the node on your own Tor onion service.
<br>
----
### useful commands and urls
<br>
#### find your ip
* private: `ifconfig | grep "inet " | grep -v 127.0.0.1`
* public: `curl v4.ident.me`
* router: `ip route | grep default` (Linux), `netstat -nr | grep default` (MacOS)
<br>
#### beacon chain checkpoint sync
* [eth panda ops](https://goerli.checkpoint-sync.ethpandaops.io)
----
### further resources
<br>
* [code for bootnodes.go](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go)
* [consensus specs for networking](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub)
* [consensus + execution mechanism](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
* [lib2p2 specs](https://github.com/libp2p/specs)
* [devp2p specs](https://github.com/ethereum/devp2p)
* [from kademlia to discv5](https://vac.dev/kademlia-to-discv5)
* [a look at hardware for staking](https://www.reddit.com/r/ethstaker/comments/j3mlup/a_slightly_updated_look_at_hardware_for_staking/)
* [configuring staking with dappnode](https://raymonddurk.medium.com/how-to-stake-for-ethereum-2-0-with-dappnode-231fa7689c02)
* [staking & hardware](https://kb.beaconcha.in/saking-and-hardware)
* [love weak subjectivity, by vitalik](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity)
* [post-merge mev: modelling validator returns](https://pintail.xyz/posts/post-merge-mev/)
* [post-merge apy analysis by rocketpool](https://github.com/rocket-pool/rocketpool-research/blob/master/Post%20Merge/Analysis.md)
* [rated's baseline mev computation](https://rated.gitbook.io/rated-documentation/rating-methodologies/ethereum-beacon-chain/baseline-mev-computation)

View file

@ -0,0 +1,170 @@
## 🌭 running a node
<br>
### tl; dr
* [check my step-by-step article to run validator](https://mirror.xyz/steinkirch.eth/F5PI4eqShKTGlx0GzL0Lq0-vHQ6b14OoV4ylE2FMsAc)
<br>
----
### infrastructure
<br>
#### how a node creates a block is created in ethereum:
1. the validator client requests a block from the consensus node
2. the consensus node requests an execution payload from the execution node and incorporates it into the block
3. the validator client signs the block
4. the validator client sends the signed block to the consensus node
5. the consensus node broadcasts the signed block to the network
#### how does mev affect block times:
1. the validator client requests a block without transactions (blinded block) from the consesnsus node
2. the consensus node queries multiple MEV relays for best bid, incorporating the best block into the returned binded blocl
3. the validator client signs the binded block
4. the validator client requests the consensus node to unblind and broadcast the signed block
5. the consensus node requests the winning MEV relay to unblind the singed block and broadcasts it to the network
<br>
#### solo staking
<br>
* [eth docker](https://eth-docker.net/docs/About/Overview)
* [stereum solo node infra](https://stereum.net/ethereum-node-setup/)
* [staking deposit cli](https://github.com/ethereum/staking-deposit-cli)
* [ethereum staking guides](https://github.com/SomerEsat/ethereum-staking-guides)
<br>
#### pool staking
<br>
* [stakewise](https://app.stakewise.io/)
* [rocketpool](https://rocketpool.net/)
* [lido](https://lido.fi/)
* [stafi.io](https://www.stafi.io/)
* [nice node](https://www.nicenode.xyz/)
* [ankr](https://www.ankr.com/)
* [stakefish](https://v1.stake.fish/)
<br>
#### staking as a service
<br>
* [alchemy](https://www.alchemy.com/)
* [infura](https://infura.io/)
* [kaleido](https://www.kaleido.io/)
* [moralis](https://moralis.io/)
* [nownodes](https://nownodes.io/)
* [pokt](https://www.pokt.network/)
* [watchdata](https://www.watchdata.io/)
* [zmok](https://zmok.io/)
* [quicknode](https://www.quicknode.com/)
* [rivt](https://rivet.cloud/)
* [sensei](https://www.senseinode.com/)
* [settlemint](https://console.settlemint.com/)
* [blockdaemon](https://blockdaemon.com/)
* [chainstack](https://chainstack.com/)
* [figment](https://datahub.figment.io/)
* [getblock](https://getblock.io/)
* [infstones](https://infstones.com/)
<br>
-----
### light nodes
<br>
* [running a light node with geth](https://ethereum.org/en/developers/tutorials/run-light-node-geth/)
* [ethereum arm docs](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)
<br>
----
### testnets
<br>
##### goerli
<br>
* [goerli launchpad](https://goerli.launchpad.ethereum.org/en/)
* [run a node on goerli/prater](https://notes.ethereum.org/@launchpad/goerli)
* [guide to join the goerli/prater (besu/teku)](https://github.com/remyroy/ethstaker/blob/main/merge-goerli-prater.md)
* [staking guide for goerli/parter (lighthouse)](https://agstakingco.gitbook.io/eth-2-0-staking-guide-prater-lighthouse/)
* [goerli testnet staking guides](https://github.com/SomerEsat/ethereum-staking-guides#goerli-testnet-staking-guides)
* [goerli testnet (geth/prysm)](https://kb.beaconcha.in/archive/eth1-infura)
* [how to create a merge testnet](https://notes.ethereum.org/@parithosh/H1MSKgm3F)
<br>
##### kiln
<br>
* [kiln launchpad](https://notes.ethereum.org/@launchpad/kiln) (and [here](https://kiln.launchpad.ethereum.org/en/))
* [running kiln testnet on a rasp pi 4](https://ethereum.org/en/developers/tutorials/run-node-raspberry-pi/)
<br>
----
### plug and play solutions
<br>
* [dappnode](https://dappnode.io/en-us/collections/frontpage)
* [avado](https://ava.do/)
<br>
----
### monitoring
<br>
* [guide to monitor a validator](https://github.com/remyroy/ethstaker/blob/main/monitoring.md)
* [guide to alerting a validator](https://github.com/remyroy/ethstaker/blob/main/alerting.md)
<br>
---
### other useful resources
<br>
* [ethereum.org official page on becoming a validator](https://launchpad.ethereum.org/en/overview)
* [ethereum.org official page on running a node](https://ethereum.org/en/run-a-node/)
* [how to setup a validator for eth staking guide](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet)
* [ethub docs on running a node](https://docs.ethhub.io/using-ethereum/running-an-ethereum-node/)
* [validator key generator](https://wagyu.gg/)
* [jwt decoder](https://jwt.io/)
* [eth staker community](https://ethstaker.cc/)
* [cli for managing tasks](https://github.com/wealdtech/ethdo)

View file

@ -0,0 +1,20 @@
## Notes on Searcher-Builder-Validator/Sequencer (SBV)
<br>
### tl; dr
* cooperation between proposers seems unlike in an unfair market, especially in a semi-permissionless half-centralized sequencer setup
* considering slashing risks, the incentives to become a sequencer (despite tx fees) are unclear
* having a Searcher-Builder-Validator/Sequencer supply chain could lead to trusted social contracts between all actors
* should MEV be addressed on the application layer? this generate security concerns on the underlying protocol
* a fair marketplace would let searchers to look for predictable MEV state changes with profitable actions, with the security of the protocol (with the sequencer itself)
<br>
---
### resources
* [decentralizing sequencers, by maven11](https://maven11.substack.com/i/100501772/decentralizing-sequencers)

View file

@ -0,0 +1,70 @@
## 🎂 the mempool (the dark forest)
### tl;dr
<br>
* the mempool is the ethereum memory pool, where pending new txs wait to be confirmed, i.e., validated and included into new blocks.
* ethereum has a public mempool and many private mempool spaces (such as the ones provided by flashbots protect or rooks coordinator).
* this means that nodes and associated entities are entitled to configure their own rules for their mempool by allowing private (exclusive) order flow to
* txs to be included in blocks, while not visible in the public mempool.
<br>
<img width="350" alt="https://docs.google.com/presentation/d/1ADPiTVWEVQ8nBGLMRdx5GmSFdrrKi3OzsbyedOcVLWk/edit#slide=id.g141d1b1a5ae_0_165" src="https://user-images.githubusercontent.com/1130416/202612298-771cfd9d-b241-491e-8dc0-a277d5d0fa89.png">
<br>
### mempool monitoring providers
* [blocknative multichain dashboard](https://explorer.blocknative.com/)
* [bloXroute, via websockets](https://bloxroute.com/pricing/)
* [blocknative, via webshooks](https://www.blocknative.com/)
* [alchemy api endpoint](https://docs.alchemy.com/)
<br>
### mempool monitoring open-source code
* [mempool shark](https://github.com/sambacha/mempool-shark)
* [lurk the mempool](https://github.com/taarushv/helios)
* [eth-mempool-listener-rs](https://github.com/0xpanoramix/eth-mempool-listener-rs)
* [eth-mempool-listener-go](https://github.com/0xpanoramix/eth-mempool-listener-go)
* [eth-mempool-whale-watcher](https://github.com/jdgc/eth-mempool-whale-watcher)
<br>
### find extracted mev
1. look at each Ethereum's transaction trace
2. parse it and go through the token transfers
3. calculate the starting balance of the sender address and its ending balance (taking into account proxy addresses)
<br>
```
Extracted MEV = Successful MEV transactions + Successful MEV transactions gas fees + Failed MEV transactions gas fees
Failed MEV transactions gas fees = Reverted MEV transactions gas fees + Checked MEV transactions gas fees
```
<br>
### references
<br>

View file

@ -0,0 +1,18 @@
## mev on optimism
<br>
### in this dir
* [optimistic rollups](optimistic_rollups.md)
<br>
---
### resources
* [intro to mev auctions](https://www.mev.wiki/solutions/faas-or-meva/optimism)

View file

@ -0,0 +1,16 @@
## optimistic rollups
<br>
### tl; dr
<br>
* in optimistic rollups, txs are batched up and the state root (same as zkrs) alongside the calldata (the tx state) is sent to the l2 contract on ethereum
* dispute period can cause actual finality of txs to not happen until around a week later
<br>
<img width="822" alt="Screen Shot 2023-02-07 at 10 57 12 AM" src="https://user-images.githubusercontent.com/1130416/217339712-014ca13c-b542-4a92-a2c9-857839f3be30.png">

View file

@ -0,0 +1,20 @@
## polygon
<br>
### tl; dr
<br>
<br>
---
### resources
<br>
* [arbitrage smart contract](https://github.com/OnlyF0uR/Polygon-Arbitrage-Contract)
* [flashloan on polygon](https://github.com/yuichiroaoki/poly-flash)

View file

@ -0,0 +1,19 @@
## 🍍 mev on solana
### tl; dr
<br>
---
### resources
* [Jito.wtf](https://jito.wtf/)
* [MEV 2.0: the rise of MPSVs](https://www.recvc.com/mev-2-0-the-rise-of-mpsvs/)
* [Solana network statistics](https://jito.retool.com/embedded/public/7e37389a-c991-4fb3-a3cd-b387859c7da1)
* [MEV bots on more than $2 Million in less than an minute](https://twitter.com/oraprotocol/status/1539664843816333312?s=20&t=Hdo4irxrDiatM4LKA3FbhA)
* [Solana MEV Outlook](https://medium.com/chorus-one/analyzing-mev-instances-on-solana-part-3-6376bcf40b6b)
* [MEV-ARB-90-0322 on Misaka](https://github.com/0xMisaka/MEV-data-solana/blob/main/MEV-ARB-90-0322.ipynb0)
* [mango market liquidator bot](https://github.com/blockworks-foundation/liquidator-v3)