feat(mkdocs): blog (#1)

.docs/overrides/main.html

@@ -5,4 +5,24 @@
   <a href="{{ '../' ~ base_url }}/latest-release/">
     <strong>Click here for the latest release documentation.</strong>
   </a>
+{% endblock %}
+
+
+{% block config %}
+  {{ super() }}
+  {% if config.plugins.search %}
+    <script>
+      // Make the search query replace _-. by spaces to extend the search to all RPC methods
+      // see https://github.com/hyperledger/besu-docs/issues/448
+      var search = {
+        transform: function(query) {
+          var transformedQuery = query
+            .replace(/[\_\-\.]/g, " ")
+            .trim()
+          console.log(transformedQuery)
+          return transformedQuery
+        }
+      }
+    </script>
+  {% endif %}
 {% endblock %}

build.sh

@@ -21,23 +21,22 @@ npm install
 
 
 mkdir -p site/.well-known
-mkdocs build --clean  --site-dir site/
+INSIDERS=1 mkdocs build --clean  --site-dir site/
 date "+%Y-%m-%dT%H:%M:%S%z" > site/build_id.txt
 
 #TZ=UTC git show --quiet --date="format-local:%Y.%-m.%-d" --format="nightly-%cd" > site/.well-known/nightly-release.txt
 #cp nightly-release.txt site/.well-known/nightly-release.txt
 # git config user.name github-actions[bot]
-export GIT_COMMITTER_NAME='github-actions[bot]'
+#export GIT_COMMITTER_NAME='github-actions[bot]'
 # git config user.email 41898282+github-actions[bot]@users.noreply.github.com
 
 #export GIT_COMMITTER_EMAIL='41898282+github-actions[bot]@users.noreply.github.com'
 #export GIT_COMMITTER_DATE=2024-04-26
 
-GIT_COMMITTER_EMAIL='41898282+github-actions[bot]@users.noreply.github.com' GIT_AUTHOR_DATE="Fri Apr 26 23:36:15 PDT 2024" GIT_COMMITTER_DATE="Fri Apr 26 23:36:15 PDT 2024" git init && git add . && git commit --allow-empty --allow-empty-message -m '' && git branch -M gh-pages
-mike deploy --push --ignore-remote-status --allow-empty --update-aliases 0.2.1 latest
+#GIT_COMMITTER_EMAIL='41898282+github-actions[bot]@users.noreply.github.com' GIT_AUTHOR_DATE="Fri Apr 26 23:36:15 PDT 2024" GIT_COMMITTER_DATE="Fri Apr 26 23:36:15 PDT 2024" git init && git add . && git commit --allow-empty --allow-empty-message -m '' && git branch -M gh-pages
+# mike deploy --push --ignore-remote-status --allow-empty --update-aliases 0.2.1 latest
 # 
 #mike deploy v0.1.1
-touch site/.nojekyll
 
 
 cp platform-docs.xml site/.well-known/platform-docs.xml
@@ -50,4 +49,4 @@ echo "Build Artifact is available at: site/build_id.txt"
 
 sleep 1
 
-echo "Build completed successfully"
+echo "Build completed successfully"

commit-ts.txt

@@ -1 +1 @@
-1714331062
+1715358786

copyright.yml

@@ -5,4 +5,4 @@ copyright: |
   <p>
     &#169; 2024 The Contributors. Documentation distributed under
     <a href="https://creativecommons.org/licenses/by-nc-nd/2.5/">CC-BY-NC-ND-2.5</a>.
-  </p>
+  </p>

docs/Clients/clients.md

@@ -75,6 +75,7 @@ Here's the full sequence from the perspective of a non-validator node:
    `hardhat`, or `foundry`.
 
 2. The execution client receives the transaction and:
+
     1. Validates it (checks the user has enough ETH, the signature matches,
        etc).
 
@@ -85,6 +86,7 @@ Here's the full sequence from the perspective of a non-validator node:
        nodes. Other execution nodes include it in their mempools.
 
 3. A validator node is selected as a block proposer. As a proposer:
+
     1. Their execution client bundles many transactions from its mempool into a
        block.
 
@@ -95,7 +97,6 @@ Here's the full sequence from the perspective of a non-validator node:
        "execution payload") and adds consensus layer information, like
        attestations, slashings, rewards, penalties, etc. The execution payload +
        consensus metadata forms a "beacon block".
-
     4. The beacon block is signed and sent over the consensus gossip layer to
        other nodes.
 
@@ -111,9 +112,10 @@ Here's the full sequence from the perspective of a non-validator node:
        transactions are applied and the state is changed and up to date.
 
 [^1]:
-   The Ethereum network is not a networked database: It's a series of tubes. And if
-   you don't understand, those tubes can be filled and if they are filled, when you
-   put your message in, it gets in line and it's going to be delayed by anyone that
-   puts into that tube enormous amounts of material, enormous amounts of material.
-    Ted Stevens (2024) Wikipedia. Available at:
-    https://en.wikipedia.org/wiki/Ted_Stevens (Accessed: 03 April 2024).
+
+The Ethereum network is not a networked database: It's a series of tubes. And if
+you don't understand, those tubes can be filled and if they are filled, when you
+put your message in, it gets in line and it's going to be delayed by anyone that
+puts into that tube enormous amounts of material, enormous amounts of material.
+Ted Stevens (2024) Wikipedia. Available at:
+https://en.wikipedia.org/wiki/Ted_Stevens (Accessed: 03 April 2024).

docs/Clients/requirements.md

@@ -4,34 +4,32 @@ description: Forward Contracts in the Primary market
 tags: ["Forward Contracts", "gas auction", "mechanism design"]
 ---
 
-
 ## Required Validator Endpoints
 
-
-- /eth/v1/validator/attestation_data
-- /eth/v1/beacon/headers/{block_id}
-- /eth/v1/beacon/states/{state_id}/finality_checkpoints
-- /eth/v1/beacon/states/{state_id}/fork
-- /eth/v1/beacon/headers
-- /eth/v1/validator/liveness
-- /eth/v1/node/syncing
-- /eth/v1/config/deposit_contract
-- /eth/v1/beacon/states/{state_id}/committees
-- /eth/v1/validator/duties/attester/{epoch}
-- /eth/v1/validator/duties/proposer/{epoch}
-- /eth/v1/validator/duties/sync/{epoch}
-- /eth/v1/beacon/genesis
-- /eth/v1/validator/prepare_beacon_proposer
-- /eth/v1/beacon/pool/attestations
-- /eth/v1/beacon/blinded_blocks
-- /eth/v1/beacon/blocks
-- /eth/v1/beacon/pool/voluntary_exits
-- /eth/v1/validator/register_validator
-- /eth/v1/beacon/states/{state_id}/validators
-- /eth/v1/validator/aggregate_attestation
-- /eth/v1/validator/aggregate_and_proofs
-- /eth/v1/validator/contribution_and_proofs
-- /eth/v1/validator/beacon_committee_subscriptions
-- /eth/v1/beacon/pool/sync_committees
-- /eth/v1/beacon/blocks/{block_id}/root
-- /eth/v1/validator/sync_committee_contribution
+-   /eth/v1/validator/attestation_data
+-   /eth/v1/beacon/headers/{block_id}
+-   /eth/v1/beacon/states/{state_id}/finality_checkpoints
+-   /eth/v1/beacon/states/{state_id}/fork
+-   /eth/v1/beacon/headers
+-   /eth/v1/validator/liveness
+-   /eth/v1/node/syncing
+-   /eth/v1/config/deposit_contract
+-   /eth/v1/beacon/states/{state_id}/committees
+-   /eth/v1/validator/duties/attester/{epoch}
+-   /eth/v1/validator/duties/proposer/{epoch}
+-   /eth/v1/validator/duties/sync/{epoch}
+-   /eth/v1/beacon/genesis
+-   /eth/v1/validator/prepare_beacon_proposer
+-   /eth/v1/beacon/pool/attestations
+-   /eth/v1/beacon/blinded_blocks
+-   /eth/v1/beacon/blocks
+-   /eth/v1/beacon/pool/voluntary_exits
+-   /eth/v1/validator/register_validator
+-   /eth/v1/beacon/states/{state_id}/validators
+-   /eth/v1/validator/aggregate_attestation
+-   /eth/v1/validator/aggregate_and_proofs
+-   /eth/v1/validator/contribution_and_proofs
+-   /eth/v1/validator/beacon_committee_subscriptions
+-   /eth/v1/beacon/pool/sync_committees
+-   /eth/v1/beacon/blocks/{block_id}/root
+-   /eth/v1/validator/sync_committee_contribution

docs/Clients/validators.md

@@ -2,7 +2,8 @@
 title: Validators
 ---
 
-This is a block diagram of all the parts of the system and will be updated as needed.
+This is a block diagram of all the parts of the system and will be updated as
+needed.
 
 ```mermaid
 graph LR

docs/Developers/index.md

@@ -4,8 +4,6 @@ description:
     Developer related information for builders, searchers and intergrators.
 ---
 
-
-
 ## General
 
 -   [SDK](./sdk.md)
@@ -16,7 +14,6 @@ description:
 
 -   [Interface](./interface.md)
 
-
 ### Builder and Searcher specific
 
 [Requirements](./builders.md)

docs/Reference/glossary.md

@@ -35,4 +35,3 @@ title: Glossary
 | Block Proposal                       | The process by which validators or miners propose a set of transactions to be included in a new block.                                            |
 | Staking                              | The act of locking up cryptocurrency holdings to support the operation of a blockchain network, often in exchange for rewards.                    |
 | Epoch                                | A division of time used in blockchain networks, referring to a set period during which certain processes or updates occur.                        |
-

docs/Relay/index.md

@@ -2,46 +2,23 @@
 title: Relay
 ---
 
-## Comparision
+# ValidatorRegistration
 
-| **Name**                           | **MEV Auction Platform ** | **Paradigm Merkle.io**                              | **Kolibrio** | **BloXroute** | **MEV-Blocker** | **MEV-Share** |
-| ---------------------------------- | ------------------------- | --------------------------------------------------- | ------------ | ------------- | --------------- | ------------- |
-| Revenue                            |                           | 90% of MEV,guaranteed at least$0.02 per transaction | 90% of MEV   | 90% of MEV    | $0              | $0            |
-| Future Inclusion                   | ✔︎                       | ✕                                                   |              |               |                 |               |
-| MEV Boost Compatible               | ✔︎                       | ✔︎                                                 |              |               |                 |               |
-| New Trust Assumptions              |                           | ✔︎                                                 | ✔︎          | ✔︎           | ✔︎             | ✔︎           |
-| Exclude Reverting Transactions     |                           | ✔︎                                                 |              |               |                 |               |
-| Multi Block Support                |                           | ✔︎                                                 |              |               |                 |               |
-| Latency based                      | ✕                         | ✔︎                                                 |              |               |                 |               |
-| Requires RPC Connection            | ✕                         | ✔︎                                                 | ✔︎          | ✔︎           | ✔︎             | ✔︎           |
-| Requires Block Builder integration | ✕                         | ✔︎                                                 |              |               |                 |               |
-| Dashboard                          |                           | theta                                               | ox           | ox            | ox              | ox            |
-| Compliant                          |                           | theta                                               | ox           | ox            | ox              | ox            |
-| Programmable privacy               |                           | Theta                                               | ox           | ox            | ox              | Theta         |
-| Status API                         |                           | theta                                               | ox           | ox            | ox              | theta         |
-| Advanced API                       |                           | Theta                                               | ox           |               |                 | ox            |
-| Dedicated RPC                      |                           | theta                                               |              |               | Theta           | theta         |
-| Fast inclusion                     |                           | theta                                               | ox           | Theta         | Theta           |               |
-| MEV Protection                     |                           | theta                                               | Theta        | Theta         | Theta           | theta         |
-| Chains                             |                           |                                                     |              |               |                 |               |
-| Ethereum                           |                           | Theta                                               | Theta        | Theta         | Theta           | Theta         |
-| Polygon                            | ✕                         | theta                                               | Theta        | Theta         | ox              | ox            |
-| Binance Smart Chain                | ✕                         | ( )                                                 | Theta        | Theta         | ox              | ox            |
-| Total                              |                           |                                                     |              |               |                 |               |
+## Properties
 
-## Strategies
+| Name              | Type       | Description                             | Notes             |
+| ----------------- | ---------- | --------------------------------------- | ----------------- |
+| **fee_recipient** | **String** | Address to receive fees from the block. | [default to null] |
+| **gas_limit**     | **String** | Preferred gas limit of validator.       | [default to null] |
+| **timestamp**     | **String** | Unix timestamp of registration.         | [default to null] |
+| **pubkey**        | **String** | BLS public key of validator.            | [default to null] |
 
-## Latency Based
+# ValidatorsResponseEntry
 
-Latency strategies within relay operations carry significant implications for
-relay competitiveness. The practical upshot is that some relays can only
-consistently compete through an artificial delay. An extreme case of this would
-be a relay which is technically consistently non-competitive, but captures
-exclusive order flow – in this case, a rational node operator will always query
-it with an artificial latency parameter.
+## Properties
 
-This competition among relays hints at a potential shift in the game, where
-relays might strategically delay responses to enhance their chances of providing
-the best bid. This adaptation could be likely incentivized by the benefits of
-optimized delay, particularly for vertically-integrated builders who may be
-inclined to pay a premium for more reliable bid inclusion.
+| Name                | Type                                            | Description | Notes                        |
+| ------------------- | ----------------------------------------------- | ----------- | ---------------------------- |
+| **slot**            | **String**                                      |             | [optional] [default to null] |
+| **validator_index** | **String**                                      |             | [optional] [default to null] |
+| **entry**           | [**getValidators_200_response_inner_entry**](#) |             | [optional] [default to null] |

docs/blog/.authors.yml

@@ -0,0 +1,5 @@
+authors:
+  sambacha:
+    name: Sam Bacha
+    description: Janitor
+    avatar: https://avatars.githubusercontent.com/u/32783916?v=4

docs/blog/index.md

@@ -0,0 +1 @@
+# Blog

docs/blog/posts/v0-roadmap.md

@@ -0,0 +1,34 @@
+---
+date: 2024-05-10
+authors:
+    - sambacha
+categories:
+    - announcements
+    - changelog
+---
+
+# Timeline for v0 to v1
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla.
+Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec
+semper lorem quam in massa.
+
+<!-- more -->
+
+```mermaid
+timeline
+    title Timeline of Key Events
+    dateFormat MM-DD
+    section Deployment and Governance
+    May 14th : Rollup Deployment
+    May 17th : v1 Main Net Enabled
+    May 20th : Governance Proposal Submitted
+    May 24th : First Week of Data Available
+
+    section Meetings and Voting
+    May 30th : Ethereum ACD Meeting
+    May 30th : Lido DAO Snapshot Voting Period Starts
+    June 6th : Lido DAO Snapshot Voting Period Ends
+```
+
+Read the forum post here

docs/index.md

@@ -4,7 +4,7 @@ description: The Gang Designs the Ultimate MEV Auction
 date: 2024-04-24
 ---
 
-## MEV Auction
+# MEV Auction
 
 Multi-unit auctions, unlike their single-unit counterparts, present complex
 allocation mechanisms. The MEV Auction platform implements several innovative

docs/javascripts/extra.js

@@ -29,14 +29,19 @@ document$.subscribe(() => {
   MathJax.typesetPromise();
 });
 
-$( document ).ready(function() {
+/* global $ */
+$(document).ready(function () {
   displayLatestWarning();
 });
 
-$(window).on('hashchange', function(){
+$(window).on('hashchange', function () {
   displayLatestWarning();
 });
 
-function displayLatestWarning(){
-  $( ".latest-warning" ).css( "display", $(location).attr('href').includes(latestWarningTrigger)?"block":"none" );
-}
+function displayLatestWarning() {
+  const latestWarningTrigger = '/latest-warning'; // Declare and initialize latestWarningTrigger
+  $('.latest-warning').css(
+    'display',
+    $(location).attr('href').includes(latestWarningTrigger) ? 'block' : 'none',
+  );
+}