From fa8c9968b6cd7cce735b8a74c4ad8be7a07cf1b9 Mon Sep 17 00:00:00 2001 From: Sebastien Guillemot Date: Mon, 11 Mar 2024 16:33:13 +0900 Subject: [PATCH] Improve parallel funnel readability --- .../500-parallel-evm-funnel.mdx | 20 +++--- .../parallel-evm-funnel-merge.svg | 70 +++++++++---------- .../3-funnel-types/parallel-finalized.svg | 35 +++++++--- 3 files changed, 73 insertions(+), 52 deletions(-) diff --git a/docs/home/300-react-to-events/3-funnel-types/500-parallel-evm-funnel.mdx b/docs/home/300-react-to-events/3-funnel-types/500-parallel-evm-funnel.mdx index 170ab689..c1b67f9a 100644 --- a/docs/home/300-react-to-events/3-funnel-types/500-parallel-evm-funnel.mdx +++ b/docs/home/300-react-to-events/3-funnel-types/500-parallel-evm-funnel.mdx @@ -31,10 +31,10 @@ This funnel has the following steps: Merging of data is done in a way to ensure that the state transition is deterministic. -For example, -if on the main chain we have blocks with timestamps 3 and 5, -and on the parallel chain we have blocks with timestamps 4 and 5, -the events in the parallel chain will look as if they happened in the main chain's block that has timestamp 5. +For example,
+if on the main chain we have blocks with timestamps 3 and 5,
+and on the parallel chain we have blocks with timestamps 4 and 5,
+the events in the parallel chain will look as if they happened in the main chain's block that has timestamp 5. And this is always the same regardless of the time of the sync, since the chains are always processed in tandem. Note that is possible that there may not be blocks to merge at a certain point. @@ -44,16 +44,18 @@ Note that is possible that there may not be blocks to merge at a certain point. We cannot go back in time to add information to old blocks that have already been parsed by the game's state machine. Therefore, it means that a block can only be considered finalized and ready to be given to the state machine once we're certain we have all the information for all chains being monitored. -The only way for us to know that we have all the information for a block is if the latest timestamp of all networks we're monitoring is more recent than the timestamp of the main chain block timestamp we're looking at. +The only way for us to know that we have all the information for a block is if the latest timestamp of all networks we're monitoring is more recent (not equal since some networks have multiple blocks with the same timestamp) than the timestamp of the main chain block timestamp we're looking at. *Note*: this behavior helps protect apps built with Paima from getting in a bad state. If an RPC you're connecting to for a network gets stuck, it should stop block production for the entire application. Otherwise, it can break determinism because your node (that is missing events from the parallel chain RPC that is stuck) will see a different block history from somebody else running a node connecting to a properly functioning RPC for that parallel chain. -Because of this, leveraging parallel funnels has multiple performance implications. In some cases the performance impact can be mitigated by [emulated blocks](./400-stable-tick-rate-funnel.mdx), -but we will cover all performance implications in this section - +## Performance implications + +Leveraging parallel funnels has multiple performance implications. In some cases the performance impact can be mitigated by [emulated blocks](./400-stable-tick-rate-funnel.mdx), +but we will cover all performance implications in this section + ### Networking overhead From Paima's perspective, a block can only be considered complete and ready to send to the game's state machine after it's fetched all necessary information. @@ -87,7 +89,7 @@ We achieve this in 2 steps: When booting up Paima Engine, there are 2 blocks we are interested in knowing: 1. When the [presync](./1-intro.md#readpresyncdata-function) ends (the last block in the parallel chain that appears before the main chain starting block height) -2. Most recent parallel chain block that appears before the next main chain block we have to sync +2. The earliest parallel chain block that whose events might be included in the next main chain block we have to sync Syncing blocks one-by-one until we find these points would be too slow. To solve this, we instead use [binary search](https://simple.wikipedia.org/wiki/Binary_search) to find and cache these blocks on boot. diff --git a/docs/home/300-react-to-events/3-funnel-types/parallel-evm-funnel-merge.svg b/docs/home/300-react-to-events/3-funnel-types/parallel-evm-funnel-merge.svg index 78decb36..4cbcc64b 100644 --- a/docs/home/300-react-to-events/3-funnel-types/parallel-evm-funnel-merge.svg +++ b/docs/home/300-react-to-events/3-funnel-types/parallel-evm-funnel-merge.svg @@ -1,37 +1,37 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/home/300-react-to-events/3-funnel-types/parallel-finalized.svg b/docs/home/300-react-to-events/3-funnel-types/parallel-finalized.svg index 4590212a..54d1b49f 100644 --- a/docs/home/300-react-to-events/3-funnel-types/parallel-finalized.svg +++ b/docs/home/300-react-to-events/3-funnel-types/parallel-finalized.svg @@ -1,4 +1,4 @@ - + @@ -8,15 +8,33 @@ - - + + - - - + + + + + + + + + + + + + + + + + + + + + @@ -31,6 +49,7 @@ - - + + +