diff --git a/docs/asssets/Coherence.png b/docs/assets/Coherence.png similarity index 100% rename from docs/asssets/Coherence.png rename to docs/assets/Coherence.png diff --git a/docs/asssets/Consensus-Engine-Page-1.png b/docs/assets/Consensus-Engine-Page-1.png similarity index 100% rename from docs/asssets/Consensus-Engine-Page-1.png rename to docs/assets/Consensus-Engine-Page-1.png diff --git a/docs/asssets/Consensus-Engine-Page-2.png b/docs/assets/Consensus-Engine-Page-2.png similarity index 100% rename from docs/asssets/Consensus-Engine-Page-2.png rename to docs/assets/Consensus-Engine-Page-2.png diff --git a/docs/asssets/Consensus-Engine-Page-3.png b/docs/assets/Consensus-Engine-Page-3.png similarity index 100% rename from docs/asssets/Consensus-Engine-Page-3.png rename to docs/assets/Consensus-Engine-Page-3.png diff --git a/docs/asssets/Consensus-Engine-Page-4.png b/docs/assets/Consensus-Engine-Page-4.png similarity index 100% rename from docs/asssets/Consensus-Engine-Page-4.png rename to docs/assets/Consensus-Engine-Page-4.png diff --git a/docs/asssets/Consensus-Engine-Page-5.png b/docs/assets/Consensus-Engine-Page-5.png similarity index 100% rename from docs/asssets/Consensus-Engine-Page-5.png rename to docs/assets/Consensus-Engine-Page-5.png diff --git a/docs/asssets/Pool-eip1559.png b/docs/assets/Pool-eip1559.png similarity index 100% rename from docs/asssets/Pool-eip1559.png rename to docs/assets/Pool-eip1559.png diff --git a/docs/asssets/Subpools.png b/docs/assets/Subpools.png similarity index 100% rename from docs/asssets/Subpools.png rename to docs/assets/Subpools.png diff --git a/docs/asssets/arch2.png b/docs/assets/arch2.png similarity index 100% rename from docs/asssets/arch2.png rename to docs/assets/arch2.png diff --git a/docs/asssets/cfg1.png b/docs/assets/cfg1.png similarity index 100% rename from docs/asssets/cfg1.png rename to docs/assets/cfg1.png diff --git a/docs/asssets/erigon2_profile.png b/docs/assets/erigon2_profile.png similarity index 100% rename from docs/asssets/erigon2_profile.png rename to docs/assets/erigon2_profile.png diff --git a/docs/asssets/mgr-sync-1.png b/docs/assets/mgr-sync-1.png similarity index 100% rename from docs/asssets/mgr-sync-1.png rename to docs/assets/mgr-sync-1.png diff --git a/docs/asssets/minimal-perfect.png b/docs/assets/minimal-perfect.png similarity index 100% rename from docs/asssets/minimal-perfect.png rename to docs/assets/minimal-perfect.png diff --git a/docs/asssets/perfect-hash.png b/docs/assets/perfect-hash.png similarity index 100% rename from docs/asssets/perfect-hash.png rename to docs/assets/perfect-hash.png diff --git a/docs/asssets/pos_downloader.png b/docs/assets/pos_downloader.png similarity index 100% rename from docs/asssets/pos_downloader.png rename to docs/assets/pos_downloader.png diff --git a/docs/asssets/regular-hash.png b/docs/assets/regular-hash.png similarity index 100% rename from docs/asssets/regular-hash.png rename to docs/assets/regular-hash.png diff --git a/docs/asssets/stagedsync_proportions.png b/docs/assets/stagedsync_proportions.png similarity index 100% rename from docs/asssets/stagedsync_proportions.png rename to docs/assets/stagedsync_proportions.png diff --git a/docs/asssets/state_composition.png b/docs/assets/state_composition.png similarity index 100% rename from docs/asssets/state_composition.png rename to docs/assets/state_composition.png diff --git a/docs/asssets/tx_types.png b/docs/assets/tx_types.png similarity index 100% rename from docs/asssets/tx_types.png rename to docs/assets/tx_types.png diff --git a/docs/merry-go-round-sync.md b/docs/merry-go-round-sync.md index fd546875688..73a32140fc2 100644 --- a/docs/merry-go-round-sync.md +++ b/docs/merry-go-round-sync.md @@ -17,7 +17,7 @@ Cycle is divided into ticks. For convenience, we can say that each ticks starts for some predetermined amount of time, let's say, 30 seconds. This definition means that the ticks will often overlap, but not always, as shown on the picture below. -![cycles-and-ticks](./asssets/mgr-sync-1.png) +![cycles-and-ticks](./assets/mgr-sync-1.png) If chain reorgs occur, and the timings of recent Ethereum blocks change as a result, we can accept these rules to prevent the reorgs to be used to disrupt the sync. Imagine the tick started at block A (height H), and then due to reorg, block A diff --git a/txnprovider/txpool/README.md b/txnprovider/txpool/README.md index 3c24644ee9a..201e2b33fd0 100644 --- a/txnprovider/txpool/README.md +++ b/txnprovider/txpool/README.md @@ -16,7 +16,7 @@ tx_hash => transaction ## Send notifications about new pending transactions There are RPC methods that allow subscribing to new pending transactions. First of all, we need to define what "new pending" transaction means. Our current understanding of this terminology is illustrated below. -![](https://github.com/erigontech/erigon/blob/main/docs/assets/tx_types.png) +![](/docs/assets/tx_types.png) Out of all transaction arriving at the pool, there are those that are valid on the current state. Good test for those is: "If we were to produce a block with unlimited block gas limit, as large as possible, which transactions would we include?". This set of transactions is shown as light green circle. @@ -77,7 +77,7 @@ tx_hashes, pending_pool, queued_pool, local_transactions => pending_pool`, queue where modified pending pool and queued pool, and local transactions do not contain given transaction hashes anymore. -In code can find production of such event by `p.newPendingTxs <-`, and handling of this event by `announcements := <-newTxs` here https://github.com/erigontech/erigon/blob/main/txpool/pool.go#L1429 +In code can find production of such event by `p.newPendingTxs <-`, and handling of this event by `announcements := <-newTxs` [here](pool.go#L1429) ## Reinject transactions into the transaction pool on unwinding a block This can be thought of a reverse operation from the one described before. When a block that was deemed "the best" of its height, is no longer deemed "the best", the transactions contained in it, are now viable for inclusion in other blocks, and therefore should be returned into the transaction pool. We can describe this function as: @@ -101,7 +101,7 @@ Another challenge (solvable) of persisting transactions (for example, local tran ## Changes for EIP-1559 -![](https://github.com/erigontech/erigon/blob/main/docs/assets/Pool-eip1559.png) +![](/docs/assets/Pool-eip1559.png) With the EIP-1559, there are a few changes to the transaction pool model described above. Now it is possible for transactions to become executable or not without any changes to the sender's balance or nonce. This is because there is a rule that `feeCap` of a transaction needs to be no less than `baseFee` of the block, for the transaction to be includable. @@ -124,7 +124,7 @@ First ephemeral field is an integer that acts as a bitfield, we call it `SubPool Currently there are five bits in the `SubPool` ephemeral field, so it is an integer `0..31`. These integers can be directly compared, and the largest value means a transaction is more preferable. This ephemeral field allows us to stratify all transactions into three sub pools (hence the name of the field). -![](https://github.com/erigontech/erigon/blob/main/docs/assets/Subpools.png) +![](/docs/assets/Subpools.png) There are three subpools - pending (green), basefee (yellow), and queued (red). Each subpool consists of two sorting data structures, one of which sorts transactions in the order of decreasing priority ("best" structure), another - in the order of increasing priority ("worst" structure). For yellow and red subpools, the sorting data structures are priority queues. For the green pool, the "best" structure could be priority queue, but it may be more convenient to have it as a list, to avoid frequent popping and pushing elements in and out of priority queue. Worst data structures serve to restrict the size of a subpool. The restriction can be defined either in terms of number of transactions, or in terms of total size of transactions (in bytes). Worst data structure allows taking the "worst" elements from the pool (and either demoting them into lower pools, or discarding them), that is why it needs to order transactions from the lowest priority to the highest. @@ -308,7 +308,7 @@ Firstly, we now specified what was the expected block height and the block hash Having this modified interface, it would be possible to batch the forward updates for multiple blocks into one. But perhaps more importantly, it allows the "client side" (tx pool, or RPC daemon, or other system where state cache is used) to detect the lost messages, and invalidate the state cache if it happens. -![](https://github.com/erigontech/erigon/blob/main/docs/assets/Coherence.png) +![](/docs/assets/Coherence.png) State Cache works on top of Database Transaction and pair Cache+ReadTransaction must provide "Serializable Isolation Level" semantic: all data form consistent db view at moment when read transaction started, read data are immutable until end of read transaction, reader can't see newer updates.