Merge branch 'dev' into all-contributors/add-juliettech13

Author: wackerow

.all-contributorsrc

@@ -11875,6 +11875,24 @@
       "contributions": [
         "tutorial"
       ]
+    },
+      "login": "0xayot",
+      "name": "0xayot",
+      "avatar_url": "https://avatars.githubusercontent.com/u/101125111?v=4",
+      "profile": "https://github.com/0xayot",
+      "contributions": [
+        "doc"
+      ]
+    },
+    {
+      "login": "lgaroche",
+      "name": "Louis",
+      "avatar_url": "https://avatars.githubusercontent.com/u/13414533?v=4",
+      "profile": "https://github.com/lgaroche",
+      "contributions": [
+        "content",
+        "bug"
+      ]
     }
   ],
   "contributorsPerLine": 7,

README.md

@@ -1820,6 +1820,8 @@ Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/d
       <td align="center" valign="top" width="14.28%"><a href="https://github.com/beetrootkid"><img src="https://avatars.githubusercontent.com/u/34025634?v=4?s=100" width="100px;" alt="kuhant"/><br /><sub><b>kuhant</b></sub></a><br /><a href="#tool-beetrootkid" title="Tools">🔧</a></td>
       <td align="center" valign="top" width="14.28%"><a href="https://github.com/LucasAschenbach"><img src="https://avatars.githubusercontent.com/u/37406743?v=4?s=100" width="100px;" alt="Lucas Aschenbach"/><br /><sub><b>Lucas Aschenbach</b></sub></a><br /><a href="#content-LucasAschenbach" title="Content">🖋</a></td>
       <td align="center" valign="top" width="14.28%"><a href="https://juliet.tech"><img src="https://avatars.githubusercontent.com/u/19226636?v=4?s=100" width="100px;" alt="juliettech"/><br /><sub><b>juliettech</b></sub></a><br /><a href="#tutorial-juliettech13" title="Tutorials">✅</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/0xayot"><img src="https://avatars.githubusercontent.com/u/101125111?v=4?s=100" width="100px;" alt="0xayot"/><br /><sub><b>0xayot</b></sub></a><br /><a href="https://github.com/ethereum/ethereum-org-website/commits?author=0xayot" title="Documentation">📖</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/lgaroche"><img src="https://avatars.githubusercontent.com/u/13414533?v=4?s=100" width="100px;" alt="Louis"/><br /><sub><b>Louis</b></sub></a><br /><a href="#content-lgaroche" title="Content">🖋</a> <a href="https://github.com/ethereum/ethereum-org-website/issues?q=author%3Algaroche" title="Bug reports">🐛</a></td>
     </tr>
   </tbody>
 </table>

public/content/developers/docs/consensus-mechanisms/pos/attestations/index.md

@@ -32,7 +32,7 @@ Finally, the validator signs the attestation and broadcasts it to the network.
 
 There is a substantial overhead associated with passing this data around the network for every validator. Therefore, the attestations from individual validators are aggregated within subnets before being broadcast more widely. This includes aggregating signatures together so that an attestation that gets broadcast includes the consensus `data` and a single signature formed by combining the signatures of all the validators that agree with that `data`. This can be checked using `aggregation_bits` because this provides the index of each validator in their committee (whose ID is provided in `data`) which can be used to query individual signatures.
 
-In each epoch a validator in each subnet is selected to be the `aggregator`. The aggregator collects all the attestations it hears about over the gossip network that have equivalent `data` to its own. The sender of each matching attestation is recorded in the `aggregation_bits`. The aggregator then broadcasts the attestation aggregate to the wider network.
+In each epoch 16 validators in each subnet are selected to be the `aggregators`. The aggregators collect all the attestations they hear about over the gossip network that have equivalent `data` to their own. The sender of each matching attestation is recorded in the `aggregation_bits`. The aggregators then broadcast the attestation aggregate to the wider network.
 
 When a validator is selected to be a block proposer they package aggregate attestations from the subnets up to the latest slot in the new block.
 

public/content/developers/docs/data-and-analytics/index.md

@@ -42,6 +42,9 @@ Using [GraphQL](https://graphql.org/), developers can query any of the curated o
 
 To start, visit the [Ethereum quick start guide](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) to start indexing Ethereum blockchain data in minutes in a local Docker environment for testing before going live on a [SubQuery's managed service](https://managedservice.subquery.network/) or on [SubQuery's decentralised network](https://app.subquery.network/dashboard).
 
+## Ethernow - Mempool Data Program {#ethernow}
+[Blocknative](https://www.blocknative.com/) provides open access to its Ethereum historical [mempool data archive](https://www.ethernow.xyz/mempool-data-archive). This enables researchers and community good projects to explore the pre-chain layer of Ethereum Mainnet. The data set is actively maintained and represents the most comprehensive historical record of mempool transaction events within the Ethereum ecosystem. Learn more at [Ethernow](https://www.ethernow.xyz/). 
+
 ## Further Reading {#further-reading}
 
 - [Graph Network Overview](https://thegraph.com/docs/en/about/network/)

public/content/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md

@@ -162,14 +162,14 @@ Here is the extended code for getting a node in the Merkle Patricia trie:
 
 ### Example Trie {#example-trie}
 
-Suppose we want a trie containing four path/value pairs `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coin')`, `('horse', 'stallion')`.
+Suppose we want a trie containing four path/value pairs `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`.
 
 First, we convert both paths and values to `bytes`. Below, actual byte representations for _paths_ are denoted by `<>`, although _values_ are still shown as strings, denoted by `''`, for easier comprehension (they, too, would actually be `bytes`):
 
 ```
     <64 6f> : 'verb'
     <64 6f 67> : 'puppy'
-    <64 6f 67 65> : 'coin'
+    <64 6f 67 65> : 'coins'
     <68 6f 72 73 65> : 'stallion'
 ```
 
@@ -178,12 +178,12 @@ Now, we build such a trie with the following key/value pairs in the underlying D
 ```
     rootHash: [ <16>, hashA ]
     hashA:    [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ]
-    hashB:    [ <00 6f>, hashD ]
-    hashD:    [ <>, <>, <>, <>, <>, <>, hashE, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
-    hashE:    [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coin' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
+    hashB:    [ <00 6f>, hashC ]
+    hashC:    [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
+    hashD:    [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
 ```
 
-When one node is referenced inside another node, what is included is `H(rlp.encode(x))`, where `H(x) = keccak256(x) if len(x) >= 32 else x` and `rlp.encode` is the [RLP](/developers/docs/data-structures-and-encoding/rlp) encoding function.
+When one node is referenced inside another node, what is included is `H(rlp.encode(node))`, where `H(x) = keccak256(x) if len(x) >= 32 else x` and `rlp.encode` is the [RLP](/developers/docs/data-structures-and-encoding/rlp) encoding function.
 
 Note that when updating a trie, one needs to store the key/value pair `(keccak256(x), x)` in a persistent lookup table _if_ the newly-created node has length >= 32. However, if the node is shorter than that, one does not need to store anything, since the function f(x) = x is reversible.
 

public/content/developers/docs/scaling/zk-rollups/index.md

@@ -250,6 +250,7 @@ Projects working on zkEVMs include:
 - [What are zero-knowledge rollups?](https://alchemy.com/blog/zero-knowledge-rollups)
 - [STARKs vs SNARKs](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)
 - [What is a zkEVM?](https://www.alchemy.com/overviews/zkevm)
+- [ZK-EVM types: Ethereum-equivalent, EVM-equivalent, Type 1, Type 4, and other cryptic buzzwords](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4)
 - [Intro to zkEVM](https://hackmd.io/@yezhang/S1_KMMbGt)
 - [Awesome-zkEVM resources](https://github.com/LuozhuZhang/awesome-zkevm)
 - [ZK-SNARKS under the hood](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html)

public/content/developers/docs/smart-contracts/security/index.md

@@ -214,7 +214,7 @@ Decentralized governance can be beneficial, especially because it aligns the int
 
 One way of preventing problems related to on-chain governance is to [use a timelock](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/). A timelock prevents a smart contract from executing certain actions until a specific amount of time passes. Other strategies include assigning a “voting weight” to each token based on how long it has been locked up for, or measuring the voting power of an address at a historical period (for example, 2-3 blocks in the past) instead of the current block. Both methods reduce the possibility of quickly amassing voting power to swing on-chain votes.
 
-More on [designing secure governance systems](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/) and [different voting mechanisms in DAOs](https://hackernoon.com/governance-is-the-holy-grail-for-daos).
+More on [designing secure governance systems](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), [different voting mechanisms in DAOs](https://hackernoon.com/governance-is-the-holy-grail-for-daos), and [the common DAO attack vectors leveraging DeFi](https://dacian.me/dao-governance-defi-attacks) in the shared links.
 
 ### 8. Reduce complexity in code to a minimum {#reduce-code-complexity}
 
@@ -468,6 +468,8 @@ If you plan on querying an on-chain oracle for asset prices, consider using one
 
 - **[ABI Encoder](https://abi.hashex.org/)** - _A free online service for encoding your Solidity contract functions and constructor arguments._
 
+- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _Solidity Static Analyzer, traversing the Abstract Syntax Trees (AST) to pinpoint suspected vulnerabilities and printing out issues in an easy-to-consume markdown format._
+
 ### Tools for monitoring smart contracts {#smart-contract-monitoring-tools}
 
 - **[OpenZeppelin Defender Sentinels](https://docs.openzeppelin.com/defender/v1/sentinel)** - _A tool for automatically monitoring and responding to events, functions, and transaction parameters on your smart contracts._
@@ -508,7 +510,7 @@ If you plan on querying an on-chain oracle for asset prices, consider using one
 
 - **[CodeHawks](https://codehawks.com/)** - _Competitive audits platform hosting smart contracts auditing competitions for security researchers._
 
-- **[Cyfrin](https://www.cyfrin.io/)** - _Blockchain security and web3 education firm focused on EVM and Vyper based protocols._
+- **[Cyfrin](https://cyfrin.io)** - _Web3 security powerhouse, incubating crypto security through products and smart contract auditing services._
 
 - **[ImmuneBytes](https://www.immunebytes.com//smart-contract-audit/)** - _Web3 security firm offering security audits for blockchain systems through a team of experienced auditors and best-in-class tools._
 
@@ -548,6 +550,8 @@ If you plan on querying an on-chain oracle for asset prices, consider using one
 
 - **[Smart Contract Security Verification Standard](https://github.com/securing/SCSVS)** - _Fourteen-part checklist created to standardize the security of smart contracts for developers, architects, security reviewers and vendors._
 
+- **[Learn Smart Contract Security and Auditing](https://updraft.cyfrin.io/courses/security) - _Ultimate smart contract security and auditing course, created for smart contract developers looking to level up their security best practices and become security researchers._
+
 ### Tutorials on smart contract security {#tutorials-on-smart-contract-security}
 
 - [How to write secure smart contracts](/developers/tutorials/secure-development-workflow/)

public/content/translations/es/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md

@@ -164,14 +164,14 @@ Aquí está el código extendido para obtener un nodo en el Merkle Patricia trie
 
 ### Ejemplo de Trie {#example-trie}
 
-Supongamos que queremos un trie que contenga cuatro pares ruta/valor `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coin')`, `('horse', 'stallion')`.
+Supongamos que queremos un trie que contenga cuatro pares ruta/valor `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`.
 
 En primer lugar, convertimos tanto las rutas como los valores en `bytes`. A continuación, las representaciones reales de bytes para _rutas_ se denotan con `<>`, aunque los _valores_ todavía se muestran como cadenas, denotadas por `''`, para facilitar la comprensión (estos también en realidad serían `bytes`):
 
 ```
     <64 6f> : 'verb'
     <64 6f 67> : 'puppy'
-    <64 6f 67 65> : 'coin'
+    <64 6f 67 65> : 'coins'
     <68 6f 72 73 65> : 'stallion'
 ```
 
@@ -180,12 +180,12 @@ Ahora, construimos un trie con los siguientes pares clave/valor en la base de da
 ```
     rootHash: [ <16>, hashA ]
     hashA:    [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ]
-    hashB:    [ <00 6f>, hashD ]
-    hashD:    [ <>, <>, <>, <>, <>, <>, hashE, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
-    hashE:    [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coin' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
+    hashB:    [ <00 6f>, hashC ]
+    hashC:    [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
+    hashD:    [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
 ```
 
-Cuando se hace referencia a un nodo dentro de otro nodo, lo que se incluye es `H(rlp.encode(x))`, donde `H(x) = keccak256(x) if len(x) >= 32 else x` y `rlp.encode` es la función de codificación [RLP](/developers/docs/data-structures-and-encoding/rlp).
+Cuando se hace referencia a un nodo dentro de otro nodo, lo que se incluye es `H(rlp.encode(node))`, donde `H(x) = keccak256(x) if len(x) >= 32 else x` y `rlp.encode` es la función de codificación [RLP](/developers/docs/data-structures-and-encoding/rlp).
 
 Tenga en cuenta que al actualizar un trie, es necesario almacenar el par clave/valor `(keccak256(x), x)` en una tabla de búsqueda persistente _si_ el nodo recién creado tiene una longitud >= 32. Sin embargo, si el nodo es más corto, no es necesario almacenar nada, ya que la función f(x) = x es reversible.
 

public/content/translations/fr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md

@@ -160,14 +160,14 @@ Voici le code étendu pour obtenir un nœud dans l'arbre de Merkle Patricia :
 
 ### Exemple d'arbre {#example-trie}
 
-Supposons que nous voulions un tableau contenant quatre couples chemin/valeur `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coin')`, `('horse', 'stallion')`.
+Supposons que nous voulions un tableau contenant quatre couples chemin/valeur `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`.
 
 Tout d'abord, nous convertissons les chemins et les valeurs en `bytes` (octets). Ci-dessous, les représentations réelles d'octets pour les _chemins_ sont désignées par `<>`, bien que les _valeurs_ soient toujours représentées sous forme de chaînes, désignées par `''`, pour une compréhension plus facile (elles aussi seraient en fait des `octets`) :
 
 ```
     <64 6f> : 'verb'
     <64 6f 67> : 'puppy'
-    <64 6f 67 65> : 'coin'
+    <64 6f 67 65> : 'coins'
     <68 6f 72 73 65> : 'stallion'
 ```
 
@@ -176,12 +176,12 @@ Nous construisons un tel arbre avec les paires clé/valeur suivantes dans la bas
 ```
     rootHash: [ <16>, hashA ]
     hashA:    [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ]
-    hashB:    [ <00 6f>, hashD ]
-    hashD:    [ <>, <>, <>, <>, <>, <>, hashE, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
-    hashE:    [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coin' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
+    hashB:    [ <00 6f>, hashC ]
+    hashC:    [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
+    hashD:    [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
 ```
 
-Lorsqu'un nœud est référencé à l'intérieur d'un autre nœud, ce qui est inclus est `H(rlp.encode(x))`, où `H(x) = keccak256(x) if len(x) >= 32 else x` et `rlp.encode` est la fonction d'encodage [RLP](/developers/docs/data-structures-and-encoding/rlp).
+Lorsqu'un nœud est référencé à l'intérieur d'un autre nœud, ce qui est inclus est `H(rlp.encode(node))`, où `H(x) = keccak256(x) if len(x) >= 32 else x` et `rlp.encode` est la fonction d'encodage [RLP](/developers/docs/data-structures-and-encoding/rlp).
 
 Notez que lors de la mise à jour d'un arbre, on doit stocker la paire clé/valeur `(keccak256(x), x)`dans une table de consultation persistante _si_ le nœud nouvellement créé a une longueur >= 32. Toutefois, si le nœud est plus court que cela, il n'est pas nécessaire de stocker quoi que ce soit, puisque la fonction f(x) = x est réversible.
 

public/content/translations/it/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md

@@ -160,14 +160,14 @@ Ecco il codice esteso per ottenere un nodo nel trie di Patricia Merkle:
 
 ### Esempio di Trie {#example-trie}
 
-Supponiamo di volere un trie contenente quattro coppie percorso/valore `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coin')`, `('horse', 'stallion')`.
+Supponiamo di volere un trie contenente quattro coppie percorso/valore `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`.
 
 Per prima cosa, convertiamo sia i percorsi che i valori in `bytes`. Di seguito, le rappresentazioni reali dei byte per i _percorsi_ sono denotate da `<>`, sebbene i _valori_ siano mostrati ancora come stringhe, denotate da `"`, per maggiore facilità di comprensione (anch'essi, sarebbero in realtà `bytes`):
 
 ```
     <64 6f> : 'verb'
     <64 6f 67> : 'puppy'
-    <64 6f 67 65> : 'coin'
+    <64 6f 67 65> : 'coins'
     <68 6f 72 73 65> : 'stallion'
 ```
 
@@ -176,12 +176,12 @@ Ora, costruiamo un trie di questo tipo con le seguenti coppie chiave/valore nel
 ```
     rootHash: [ <16>, hashA ]
     hashA:    [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ]
-    hashB:    [ <00 6f>, hashD ]
-    hashD:    [ <>, <>, <>, <>, <>, <>, hashE, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
-    hashE:    [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coin' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
+    hashB:    [ <00 6f>, hashC ]
+    hashC:    [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
+    hashD:    [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
 ```
 
-Quando in un nodo si fa riferimento a un altro nodo, viene inserito `H(rlp.encode(x))`, dove `H(x) = keccak256(x) if len(x) >= 32 else x` e `rlp.encode` è la funzione di codifica [RLP](/developers/docs/data-structures-and-encoding/rlp).
+Quando in un nodo si fa riferimento a un altro nodo, viene inserito `H(rlp.encode(node))`, dove `H(x) = keccak256(x) if len(x) >= 32 else x` e `rlp.encode` è la funzione di codifica [RLP](/developers/docs/data-structures-and-encoding/rlp).
 
 Nota che, aggiornando un trie, si deve memorizzare la coppia chiave/valore `(keccak256(x), x)` in una tabella di ricerca persistente _se_ il nodo appena creato ha una lunghezza >= 32. Se invece il nodo è inferiore a questo valore, non è necessario memorizzare nulla, poiché la funzione f(x) = x è reversibile.