diff --git a/.github/workflows/publish-misc-pages.yml b/.github/workflows/publish-misc-pages.yml new file mode 100644 index 000000000000..3b2e362e2b5c --- /dev/null +++ b/.github/workflows/publish-misc-pages.yml @@ -0,0 +1,36 @@ +name: Publish misc GitHub Pages +on: + push: + branches: + - next + paths: + - "yarn-project/scripts/latency-explorer/**" + +jobs: + publish: + runs-on: ubuntu-latest + steps: + - name: Checkout source repo + uses: actions/checkout@v4 + + - name: Checkout benchmark-page-data repo + uses: actions/checkout@v4 + with: + repository: AztecProtocol/benchmark-page-data + token: ${{ secrets.AZTEC_BOT_GITHUB_TOKEN }} + path: benchmark-page-data + + - name: Copy latency explorer + run: | + mkdir -p benchmark-page-data/misc/tx-latency-explorer + cp yarn-project/scripts/latency-explorer/index.html benchmark-page-data/misc/tx-latency-explorer/index.html + + - name: Push changes + working-directory: benchmark-page-data + run: | + git config user.name "AztecBot" + git config user.email "tech@aztecprotocol.com" + git add . + git diff --cached --quiet && echo "No changes to publish" && exit 0 + git commit -m "Update tx-latency-explorer from ${{ github.sha }}" + git push diff --git a/yarn-project/scripts/latency-explorer/index.html b/yarn-project/scripts/latency-explorer/index.html new file mode 100644 index 000000000000..b23f55a818f7 --- /dev/null +++ b/yarn-project/scripts/latency-explorer/index.html @@ -0,0 +1,949 @@ + + + +
+ + +Visualize expected user-perceived latency from transaction send to effects visible in the proposed chain
+This tool models the user-perceived latency from sending a transaction to seeing its effects in the proposed + chain. The lifecycle proceeds through the following stages:
+1. TX submission. The user submits a transaction to their local Aztec node.
+2. P2P propagation to proposer. The node broadcasts the TX to the P2P network. It takes one P2P + propagation delay for the TX to reach the current slot's proposer.
+3. Waiting for the next block. The proposer builds blocks in fixed-duration sub-slots within the + L2 slot. The TX must wait until the next block building window starts, since the proposer snapshots the TX pool at + the beginning of each block.
+4. Block execution. The proposer executes the transactions in the block. The actual execution + time depends on block fill (how many and how complex the transactions are). Once done, the block proposal is + broadcast to the network without waiting for the full block window to elapse.
+5. P2P propagation back. The block proposal propagates back through the P2P network to the + user's node (another one-way propagation delay).
+6. Node re-execution. The user's node re-executes the block to update its local world state + (merkle trees, nullifiers, public data). Only after this step are the transaction's effects visible in the + proposed chain.
+7. Slot wrap. If the TX arrives too late in the slot and misses all block building windows, it + must wait for the next slot's proposer to pick it up, adding up to one full slot duration of extra latency.
+Note that this models "proposed chain" visibility -- the TX effects are visible locally before checkpoint + confirmation on L1 or epoch proving.
+