feat: update blog articles (#350)

app/[lang]/blog/[slug]/page.tsx

@@ -53,7 +53,7 @@ export default function BlogArticle({ params }: any) {
       ? `/articles/${post?.id}/${post?.image}`
       : undefined
 
-  const imageAsCover = post?.coverImage ?? false
+  const imageAsCover = true
 
   if (!post) return null
   return (
@@ -63,7 +63,7 @@ export default function BlogArticle({ params }: any) {
           className={cn(
             "absolute inset-0 bg-cover",
             imageAsCover
-              ? "bg-cover after:content-[''] after:absolute after:inset-0 after:bg-black after:opacity-10 bg-center"
+              ? "bg-cover after:content-[''] after:absolute after:inset-0 after:bg-black after:opacity-20 bg-center"
               : "bg-cover-gradient"
           )}
           style={{

articles/README.md

@@ -16,7 +16,6 @@ Edit the frontmatter section at the top of the file:
 authors: ["Your Name"] # Add your name or multiple authors in an array
 title: "Your Article Title" # The title of your article
 image: "/articles/my-new-article/cover.webp" # Image used as cover,  Keep in mind the image size, where possible use .webp format, possibly images less then 200/300kb
-coverImage: true # Image will be set as cover in the blog page, if not set the default is false
 tldr: "A brief summary of your article" #Short summary
 date: "YYYY-MM-DD" # Publication date in ISO format
 canonical: "mirror.xyz/my-new-article" # (Optional) The original source URL, this tells search engines the primary version of the content

articles/learnings-from-the-kzg-ceremony.md

@@ -1,7 +1,7 @@
 ---
 authors: ["Nico"]
 title: "Learnings from the KZG Ceremony"
-image: "cover.webp"
+image: "learnings-from-the-kzg-ceremony-cover.webp"
 tldr: "This post was authored by [Nico](https://github.com/NicoSerranoP/), a frontend developer working in the [Privacy & Scaling Explorations Team (PSE)](https://appliedzkp.org/). Nico summarizes the learnings and challenges he faced during the development and deployment of the [KZG Ceremony](https://ceremony.ethereum.org/)."
 date: "2023-07-11"
 canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/naTdx-u7kyirczTLSAnWwH6ZdedfTQu1yCWQj1m_n-E"

articles/rate-limiting-nullifier-rln.md

@@ -1,7 +1,7 @@
 ---
 authors: ["curryrasul"]
 title: "Rate-Limiting Nullifier (RLN)"
-image: "cover.webp"
+image: "rate-limiting-nullifier-rln-cover.webp"
 tldr: "This post was authored by [@curryrasul](https://twitter.com/curryrasul)."
 date: "2023-08-01"
 canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/iCLmH1JVb7fDqp6Mms2NR001m2_n5OOSHsLF2QrxDnQ"

articles/retrospective-trusted-setups-and-p0tion-project.md

@@ -1,7 +1,7 @@
 ---
 authors: ["PSE Trusted Setup Team"]
 title: "Retrospective: Trusted Setups and P0tion Project"
-image: "cover.webp"
+image: "retrospective-trusted-setups-and-p0tion-project-cover.webp"
 tldr: "This post was written by the PSE Trusted Setup Team."
 date: "2025-01-15"
 canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/Cf9nYvSlATGks8IcFaHQe3H5mgZ_Va767Zk5I8jPYXk"

articles/the-power-of-crowdsourcing-smart-contract-security-for-l2-scaling-solutions.md

@@ -1,7 +1,7 @@
 ---
 authors: ["@0xDatapunk"]
 title: "The Power of Crowdsourcing Smart Contract Security for L2 Scaling Solutions"
-image: "cover.webp"
+image: ""
 tldr: "This post was authored by [@0xDatapunk](https://github.com/0xDatapunk) at [PSE Security](https://github.com/privacy-scaling-explorations/security)."
 date: "2023-07-18"
 canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/Zjgt8YUAeW8XX5-wc1f6uNI8vx-5q_qBTYR4KFRGpTE"

articles/towards_a_quantum-safe_p2p_for_ethereum.md

@@ -1,14 +1,15 @@
 ---
 authors: ["Adria Bienvenido, Guorong Du"]
 title: "Towards a Quantum-Safe P2P for Ethereum"
-image: "cover.png"
+image: "towards_a_quantum-safe_p2p_for_ethereum-cover.webp"
 tldr: "Integrating post‑quantum cryptography into Ethereum’s P2P stack is currently impractical—PQ keys and signatures are too large for UDP‑based discovery and transport—though future research on QUIC migration, composite keys, and protocol redesign may offer viable paths forward."
 date: "2025-04-22"
 ---
+
 # Towards a Quantum-Safe P2P for Ethereum
 
+## Motivation
 
-## Motivation  
 As quantum computing continues to evolve, there is increasing interest in understanding how Ethereum’s existing peer-to-peer (P2P) networking stack might adapt to emerging post-quantum (PQ) cryptographic standards. PSE members Adria and Guorong undertook a brief exploratory project to assess what adopting PQ algorithms in Ethereum’s P2P layer would entail. This exploration aimed primarily at gaining clarity around potential challenges and identifying realistic directions for future PQ-focused efforts. Ultimately, the project highlighted significant practical limitations, providing valuable insights that we hope will help inform further PQ initiatives.
 
 ## The Current Stack
@@ -23,22 +24,22 @@ Following discovery, the execution layer uses the [RLPx](https://github.com/ethe
 
 Currently, several widely used algorithms are not considered PQ safe:
 
-| Algorithm | Status   | Most Common Constructions |
-| --------- | -------- | ------------------------- |
-| RSA       | Broken   | Encryption, Authentication, Key Exchange |
-| EC        | Broken   | ECIES encryption, ECDH authenticated key exchange, pairings, BLS signature aggregation, KZG, Groth16 (though Groth16’s perfect zero-knowledge provides forward secrecy on private inputs) |
-| Hash      | Diminished  | Hash sizes must be doubled (per Grover’s algorithm); however, Poseidon is PQ safe |
+| Algorithm | Status     | Most Common Constructions                                                                                                                                                                 |
+| --------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| RSA       | Broken     | Encryption, Authentication, Key Exchange                                                                                                                                                  |
+| EC        | Broken     | ECIES encryption, ECDH authenticated key exchange, pairings, BLS signature aggregation, KZG, Groth16 (though Groth16’s perfect zero-knowledge provides forward secrecy on private inputs) |
+| Hash      | Diminished | Hash sizes must be doubled (per Grover’s algorithm); however, Poseidon is PQ safe                                                                                                         |
 
 New PQ primitives exist, but they are not “drop-in” replacements. Their differing properties require careful integration. For instance, FN-DSA includes an internal hasher, so signing the entire message is preferable over signing a digest. Most of these algorithms have undergone lengthy NIST reviews, with more expected in the future. Remember that we are already using non-standardized algorithms such as secp256k1, Keccak, Groth16, and STARKs. Sometimes "only using approved" is not a [good](https://harvardnsj.org/2022/06/07/dueling-over-dual_ec_drgb-the-consequences-of-corrupting-a-cryptographic-standardization-process/) [idea](https://crypto.stackexchange.com/questions/108017/who-originally-generated-the-elliptic-curve-now-known-as-p256-secp256r1).
 
-| Algorithm                                   | Status    | Type                                          |
-| ------------------------------------------- | --------- | --------------------------------------------- |
-| [ML-KEM (CRYSTALS-Kyber)](https://csrc.nist.gov/pubs/fips/203/final)         | Standard  | Lattice KEM                                  |
-| [ML-DSA (CRYSTALS-Dilithium)](https://csrc.nist.gov/pubs/fips/204/final)       | Standard  | Lattice Signatures                           |
-| [SLH-DSA (SPHINCS+)](https://csrc.nist.gov/pubs/fips/205/final)                 | Standard  | Hash Signatures (alternative to Dilithium if compromised) |
-| [FN-DSA (Falcon)](https://falcon-sign.info/)                                  | Pending   | Lattice Signature                            |
-| [Falcon/Labrador](https://eprint.iacr.org/2024/311)    | Research  | Aggregated Falcon Signatures                  |
-| [CSIDH](https://csidh.isogeny.org/)                          | Research  | Non-interactive key exchange (a good replacement for ECDH) |
+| Algorithm                                                                | Status   | Type                                                       |
+| ------------------------------------------------------------------------ | -------- | ---------------------------------------------------------- |
+| [ML-KEM (CRYSTALS-Kyber)](https://csrc.nist.gov/pubs/fips/203/final)     | Standard | Lattice KEM                                                |
+| [ML-DSA (CRYSTALS-Dilithium)](https://csrc.nist.gov/pubs/fips/204/final) | Standard | Lattice Signatures                                         |
+| [SLH-DSA (SPHINCS+)](https://csrc.nist.gov/pubs/fips/205/final)          | Standard | Hash Signatures (alternative to Dilithium if compromised)  |
+| [FN-DSA (Falcon)](https://falcon-sign.info/)                             | Pending  | Lattice Signature                                          |
+| [Falcon/Labrador](https://eprint.iacr.org/2024/311)                      | Research | Aggregated Falcon Signatures                               |
+| [CSIDH](https://csidh.isogeny.org/)                                      | Research | Non-interactive key exchange (a good replacement for ECDH) |
 
 Note that PQ public keys and signatures are significantly larger than current ECDSA sizes (33 bytes for public keys, 65 bytes for signatures). For example, Falcon requires a padded signature size of 666 bytes and a public key of 897 bytes (which can be combined into 1328 bytes for transport). Check this nice [Cloudflare table](https://blog.cloudflare.com/fr-fr/another-look-at-pq-signatures/).
 
@@ -46,14 +47,14 @@ Note that PQ public keys and signatures are significantly larger than current EC
 
 The following table summarizes the cryptographic substitutions proposed for each transport layer:
 
-| Transport | Feature                         | Possible Substitution          | Notes                                                |
-| --------- | ------------------------------- | ------------------------------ | ---------------------------------------------------- |
-| ENR       | secp256k1 pk+sig                | Falcon pk+sig                  | ~1.4 KB; may exceed UDP frame limits                 |
-| Discv5    | ECDH handshake                  | FN-DSA + ML-KEM                | 1.5 roundtrips (2.3 KB + 3.2 KB + 1.5 KB); may exceed UDP frame limits |
-| Discv5    | `NODES` response                | –                              | Contains ENRs; could overflow UDP frames             |
-| RLPx      | ECDH/ECIES handshake            | 2 × FN-DSA + ML-KEM + 2 × ML-KEM | ~20 KB additional overhead                           |
-| EthWire   | Transaction signatures          | Falcon                         | 1265 bytes per signature (applies to transaction signatures and calldata) |
-| Libp2p    | Noise `XX`-type handshake with secp256k1 | [Post-Quantum Noise](https://eprint.iacr.org/2022/539.pdf) (?) | –                                                  |
+| Transport | Feature                                  | Possible Substitution                                          | Notes                                                                     |
+| --------- | ---------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------- |
+| ENR       | secp256k1 pk+sig                         | Falcon pk+sig                                                  | ~1.4 KB; may exceed UDP frame limits                                      |
+| Discv5    | ECDH handshake                           | FN-DSA + ML-KEM                                                | 1.5 roundtrips (2.3 KB + 3.2 KB + 1.5 KB); may exceed UDP frame limits    |
+| Discv5    | `NODES` response                         | –                                                              | Contains ENRs; could overflow UDP frames                                  |
+| RLPx      | ECDH/ECIES handshake                     | 2 × FN-DSA + ML-KEM + 2 × ML-KEM                               | ~20 KB additional overhead                                                |
+| EthWire   | Transaction signatures                   | Falcon                                                         | 1265 bytes per signature (applies to transaction signatures and calldata) |
+| Libp2p    | Noise `XX`-type handshake with secp256k1 | [Post-Quantum Noise](https://eprint.iacr.org/2022/539.pdf) (?) | –                                                                         |
 
 The replacement for ECDH is essentially as described in the [NIST Workshop on Guidance for KEMs](https://csrc.nist.gov/csrc/media/Events/2025/workshop-on-guidance-for-kems/documents/papers/pqc-based-bidirectional.pdf); a test implementation can be found at https://github.com/adria0/pq-aka. As you can see, this construction is not a NIKE, so it requires roundtrips.
 
@@ -81,10 +82,12 @@ Compromises in dependent systems (DNSSEC, TLS) could undermine network security,
 Here, the specific target is QUIC—a transport protocol built on UDP. At the moment, the adoption of QUIC is quite [high](https://ethresear.ch/t/quic-support-among-ethereum-consensus-layer-clients/21102/1) among CL clients, and it is expected to grow in the future.
 
 We have explored migrating the key exchange part of [rust-libp2p](https://github.com/libp2p/rust-libp2p) to a PQ-safe implementation (e.g., using Kyber KEM) in [this fork](https://github.com/guorong009/rust-libp2p/tree/prefer-post-quantum). Additionally, there is an [example](https://github.com/guorong009/p2p-chat-clone). Our conclusions are as follows:
+
 - Using a KEM algorithm for key exchange does not significantly degrade communication, as the main process relies on symmetric cryptography which is less affected by quantum computing.
 - Other aspects (authentication, node ID generation, etc.) require further in-depth research but are not immediately urgent.
 
 Additionally, we have learned:
+
 - Major tech firms (Cloudflare, IBM, Google) are conducting experiments on PQ migration of networking protocols:
   - [Cloudflare's Post-Quantum for All](https://blog.cloudflare.com/post-quantum-for-all/)
   - [Microsoft's Post-Quantum TLS](https://www.microsoft.com/en-us/research/project/post-quantum-tls/)
@@ -93,14 +96,15 @@ Additionally, we have learned:
 - Their client-server experiments might be applicable to P2P networking with less effort, given that P2P combines client and server functionalities.
 
 ## A Call for Action
-    
+
 While the proposed changes are not entirely appealing as drop-in replacements, they represent initial attempts to integrate PQ cryptographic methods within the existing framework. However, these efforts highlight significant limitations and underscore the need for innovation in this area.
 
 We must reconsider transport protocols:
+
 - **Discv5 over UDP** appears impractical due to oversized ENRs and fragmented handshakes.
 - A redesign of secure discovery protocols using current PQ algorithms is necessary, supported by robust network simulations and advanced P2P engineering.
 - Transitioning to QUIC combined with a PQ-Noise approach for P2P communication appears promising as a replacement for RLPx.
 
 Techniques such as [aggregated gossip signatures](https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386) could help mitigate increased network traffic. Research into [compressing signatures and transient information after finalization](https://ethresear.ch/t/post-quantum-txs-in-the-verge/21763) is also encouraged.
 
-Despite criticisms regarding its [internal complexity](https://x.com/Narodism/status/1882362499686645938) and [limited PQ adaptation](https://discuss.libp2p.io/t/any-information-about-post-quantum-cryptography-in-libp2p/2189), libp2p—especially its Kademlia DHT—remains a candidate for evolving to meet future PQ challenges.
+Despite criticisms regarding its [internal complexity](https://x.com/Narodism/status/1882362499686645938) and [limited PQ adaptation](https://discuss.libp2p.io/t/any-information-about-post-quantum-cryptography-in-libp2p/2189), libp2p—especially its Kademlia DHT—remains a candidate for evolving to meet future PQ challenges.

components/blog/blog-article-card.tsx

@@ -26,7 +26,7 @@ export const BlogArticleCard = ({
     (image ?? "")?.length > 0 ? `/articles/${id}/${image}` : "/fallback.webp"
   return (
     <div className="flex flex-col h-full w-full">
-      <div className="relative h-48 w-full overflow-hidden bg-gray-100">
+      <div className="relative h-48 w-full overflow-hidden bg-gray-100 flex-shrink-0">
         <Image
           src={imageUrl}
           alt={title}

components/blog/blog-content.tsx

@@ -57,7 +57,7 @@ export function BlogContent({ post }: BlogContentProps) {
               </span>
               <Link
                 href="/blog"
-                className="text-black font-bold  text-base leading-6 hover:underline hover:text-anakiwa-500"
+                className="text-black font-bold text-base leading-6 hover:underline hover:text-anakiwa-500"
               >
                 View all
               </Link>
@@ -75,21 +75,26 @@ export function BlogContent({ post }: BlogContentProps) {
                 }: Article) => {
                   const url = `/blog/${id}`
                   return (
-                    <Link
-                      href={url}
+                    <div
                       key={id}
-                      className="flex-1 w-full h-full group hover:opacity-90 transition-opacity duration-300 rounded-xl overflow-hidden bg-white shadow-sm border border-slate-900/10"
+                      className="flex flex-col min-h-[400px] w-full"
                     >
-                      <BlogArticleCard
-                        id={id}
-                        image={image}
-                        title={title}
-                        date={date}
-                        content={content}
-                        authors={authors}
-                        tldr={tldr}
-                      />
-                    </Link>
+                      <Link
+                        href={url}
+                        className="flex h-full w-full group hover:opacity-90 transition-opacity duration-300 rounded-xl overflow-hidden bg-white shadow-sm border border-slate-900/10"
+                        style={{ display: "flex", flexDirection: "column" }}
+                      >
+                        <BlogArticleCard
+                          id={id}
+                          image={image}
+                          title={title}
+                          date={date}
+                          content={content}
+                          authors={authors}
+                          tldr={tldr}
+                        />
+                      </Link>
+                    </div>
                   )
                 }
               )}

styles/globals.css

@@ -172,6 +172,12 @@
   @apply block;
 }
 
+span.katex {
+  text-align: center;
+  width: 100%;
+  display: block;
+  padding: 10px 0;
+}
 /*Accordion hover state content*/
 @media screen and (max-width: 768px) {
   .accordion.hover-icon > [data-state='closed'] [data-icon='plus'] {