The UI is showing the user a message that is not understandable when they upload files larger than what's allowed:

<img width="1842" alt="image" src="https://github.com/ethereum/sourcify/assets/13069972/58c6cf9a-823a-4101-b521-ff762772e60b">


Ethereum Foundation

Fix UI message when `413 Payload Too Large`


We are building a new [Design system](https://github.com/ethereum/ethereum-org-website/issues/6284) for ethereum.org

We are at a stage where some of the components are already in Figma, and we are building page templates. 
With this in mind, we want to improve the experience of navigating our mark-down-based pages.

This template is the most used on ethereum.org, and you can find them in some use cases pages, documentation pages, and tutorials.

![Screen Shot 2022-12-12 10 47 45 AM](https://user-images.githubusercontent.com/1120748/207026771-29f8a1ab-2d84-40db-ab11-f7fc043be40c.png)


We've finalized a [proposal](https://www.figma.com/file/vMfyq3UaTUxttMGIf5nxrH/Markdown-pages-feedback?node-id=6%3A13937&t=c2y450lZmb8MyzE3-1) for these pages that involves several components.
![Screen Shot 2022-12-12 10 48 01 AM](https://user-images.githubusercontent.com/1120748/207026815-d2fa1cf3-4284-4863-9ccb-c8ebef4e7d06.png)



Please use this [Figma](https://www.figma.com/file/vMfyq3UaTUxttMGIf5nxrH/Markdown-pages-feedback?node-id=1%3A7027&t=c2y450lZmb8MyzE3-1) to leave feedback or to use comments on this issue.

![Screen Shot 2022-12-12 10 52 20 AM](https://user-images.githubusercontent.com/1120748/207027437-f134b61b-b335-466e-a222-b0fbde6fee21.png)


[DESIGN FEEDBACK] New markdown pages in the Design system

Currently there is no built-in support for tracing in the ethclient/gethclient. This involves adding 4 new methods to gethclient:

- TraceCall
- TraceTransaction
- TraceBlock
- TraceChain

Support tracing API in gethclient

https://docs.estuary.tech/Reference/SwaggerUI

Embed the Swagger UI inside docs page instead of linking

### What is wrong?

The new parser (v2 branch) only supports augmented-assignments where the LHS is an identifier. Eg `x += 1` is supported, but `x.y += 1` isn't.

### How can it be fixed

Good opportunity for someone to become familiar with the new parser, I guess.

v2 parser AugAssign stmt doesn't allow `x[0] += 1`

### Describe the bug

There are two instances where the word 'the' is duplicated

Staking withdrawals page:
- ''To try out your setup on a testnet first, visit **the the** Goerli Testnet Staking Launchpad to get started.''

Smart contract security page:
- ''Integer underflows happen for similar reasons: **the the** results of an arithmetic operation falls below the acceptable range.''

### To reproduce

Staking withdrawals page
1. Go to https://ethereum.org/en/staking/withdrawals/#faq
2. Expand the 'I operate a validator. Where can I find more information on enabling withdrawals?' question
3. Read the 2nd paragraph
4. See error

Smart contract security page
1. Go to https://ethereum.org/en/developers/docs/smart-contracts/security/#integer-underflows-and-overflows
2. Read the 2nd paragraph
3. See error

### Expected behavior

Remove duplicate 'the' from the text

The final content should be:

Staking withdrawals page
- ''To try out your setup on a testnet first, visit the Goerli Testnet Staking Launchpad to get started.''

Smart contract security page
- ''Integer underflows happen for similar reasons: the results of an arithmetic operation falls below the acceptable range.''

### Screenshots

<img width="909" alt="Screenshot 2024-01-05 at 15 40 08" src="https://github.com/ethereum/ethereum-org-website/assets/37338979/c882c583-2ec6-4531-81a9-fdabf6a6368a">
<img width="649" alt="Screenshot 2024-01-05 at 15 42 29" src="https://github.com/ethereum/ethereum-org-website/assets/37338979/a77723f8-7396-48b8-89c5-3bc510c61132">


### Desktop (please complete the following information)

All

### Smartphone (please complete the following information)

All

### Additional context

_No response_

### Would you like to work on this issue?

- [ ] Yes
- [ ] No

Fix instances of duplicated words

### Describe the bug

There are two errors on the _Active areas of Ethereum research_ page:
- 'Verkle' is misspelled as 'Verkel'
- There is a missing comma in the Community, education and outreach section

### To reproduce

Verkle typo
1. Go to https://ethereum.org/en/community/research/#recent-research-1
2. Check the 4th item on the list
3. See error

Missing comma
1. Go to https://ethereum.org/en/community/research/#community-education-and-outreach
2. Read the first paragraph
3. See error


### Expected behavior

- 'Verkel' should be changed to 'Verkle'
- A comma should be added (**...memes, teaching resources, events...**) in the following sentence:
_This might include blog posts and articles, books, podcasts, memes, teaching resources events and anything else that builds communities, welcomes new starters and educates people about Ethereum._



### Screenshots

<img width="763" alt="Screenshot 2024-01-05 at 15 27 56" src="https://github.com/ethereum/ethereum-org-website/assets/37338979/7c61faa7-4c20-4a0a-9017-f167c2e876ca">
<img width="346" alt="Screenshot 2024-01-05 at 15 28 17" src="https://github.com/ethereum/ethereum-org-website/assets/37338979/de510327-e495-4b37-9dfb-a52540151ed3">


### Desktop (please complete the following information)

All

### Smartphone (please complete the following information)

All

### Additional context

_No response_

### Would you like to work on this issue?

- [ ] Yes
- [ ] No

Fix errors on 'Active areas of research' page

Some HTTP headers required for security are not set and a 3rd party JS code is included without a checksum on https://remix.ethereum.org/ 

## Details

1. Please consider limiting the possibility of clickjacking, embedding Remix in a frame and other potentially bad things described in https://owasp.org/www-project-secure-headers/ by adding following headers to responses at  https://remix.ethereum.org/:
```
X-Frame-Options:  SAMEORIGIN
Content-Security-Policy: frame-ancestors 'none'
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: origin-when-cross-origin
X-XSS-Protection: 0
```

Also the CORS header is now set to a wildcard, so there is a possible [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) misconfiguration: `Access-Control-Allow-Origin: *`
It should be evaluated if this could be updated to allowing Remix subdomain only.

The proposed Content-Security-Policy header is also a minimal required version, it may benefit from [more precise tuning](https://owasp.org/www-project-secure-headers/#content-security-policy) based on specifics of Remix.

2. A script tag with content from 3rd party domain is not using an integrity attribute:
`<script src="https://kit.fontawesome.com/41dd021e94.js" crossorigin="anonymous"></script>`
should be updated to:
`<script src="https://kit.fontawesome.com/41dd021e94.js" integrity="sha384-o52g9S/nRjb7E0gDheriK0UVPLDYRi7q+ac3yMjKtSsIFVvVke7woNMO8uSfIHn9" crossorigin="anonymous"></script>`



Remix security improvements

### What is wrong?

A number of functions defined in [std::evm](https://github.com/ethereum/fe/blob/master/crates/library/std/src/evm.fe) take offsets and lengths for regions of memory and calldata. These should take [buffer](https://github.com/ethereum/fe/blob/master/crates/library/std/src/buf.fe) types instead.

### How can it be fixed

- implement `CalldataBuffer`, `CalldataBufferReader`
- update `revert_mem`, `return_mem`, `call_data_copy`, `code_copy`, `ext_code_copy`, `keccak256_mem`, `create`, `create2`, `call`, and `log` 

run `$ cargo test std_lib` to check changes made to `crates/library`

`std::evm` functions should take buffer types

If version can't be downloaded at first try to retry x times to mitigate errors when solc version cannot be fetched

Add retry on loadRemoteVersion

### What was wrong?

We are missing good documentation on our formatters. We should add documentation explaining how formatters work, what each of the default formatters do, and how to customize them if possible.

Since some of the middlewares moved into the formatters, this is especially important for a user's understanding of where and why certain formatting is happening.

Document Formatters

Running and matching on a specific portal hive test helps us with local development and debugging.

Example implementation in GO: https://github.com/ethereum/portal-hive/blob/main/hivesim/testmatch.go


Implement test matching pattern in hivesim-rs

### Describe the bug

Across the website, we are using the primary outline variant of the button instead of the secondary variant of the button.

E.g., in the design system, we use a secondary button (black outline) for the secondary button.

<img width="1269" alt="Screenshot 2023-07-20 at 10 00 54" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/c0ab6728-232c-4b52-a826-1d8aee743f05">

Here is the difference:

<img width="345" alt="Screenshot 2023-07-20 at 09 57 44 1" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/aab0bc09-3f24-482a-bb0b-9a84f23ff472">

However, on production, we use the primary 'outline' variant ([see Layer 2 page](https://ethereum.org/en/layer-2/)) also everywhere.

<img width="1435" alt="Screenshot 2023-07-20 at 10 02 49" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/569ce763-486f-4553-b631-f2377a0ed2e8">

We accidentally do the same on the homepage:

<img width="1494" alt="Screenshot 2023-07-20 at 10 08 33" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/d72e0fcd-6341-4107-90f7-e537c3bd67ac">


And on the docs:

<img width="1080" alt="Screenshot 2023-07-20 at 10 08 40" src="https://github.com/ethereum/ethereum-org-website/assets/62268199/bce9dae3-f1cf-49f9-bfcc-ca14cab24d6e">


### To reproduce

1. Go to 'https://ethereum.org/en/layer-2/'
1. See error


### Expected behavior

I'm currently unsure about the correct button designs. It appears that around 90% of our buttons should feature black outlines (secondary outline).

To avoid inconsistencies, I suggest we standardize all outline button variants to secondary outline buttons. We can revise this as needed once we establish clearer design rules or exceptions.

Secondary buttons styling does not correctly reflect design system

The `clef` binary is meant to be a secure key management tool, which can be used to separate key management from the actual node operation. 

It inherently uses the same data model that's already in the go-ethereum library, which is, 

* Keystore (directory with encrypted keyfiles) 
* USB-devices (hardware wallets)
* Other external backend devices accessible via the signer external protocol. 

However, there is one usecase which doesn't really fit; when a user has millions of keys. The problem with the keystore is, 

### Primary problem

- We use filesystem notifications to become aware of new keyfiles.
- When we detect a keyfile, we open the file and scan the `json` for the `address` element, and  
- add it to an internal cache of available addresses. 

This works fine for a handful of addresses, but does not scale. 
- Opening millions of files and unmarshalling json takes quite some time, 
- The internal caches are not prepared to handle millions of items, which causes extra overhead (sorting, etc). 

In order to cater for this type of usecase, we would need an additional data storage format -- not based on keystore files. A problem with keystore files, is that although the actual address is _commonly_ in the actual filename, this has never been mandated. 

### Secondary problem 

There is also a secondary problem: apart from the actual key data, `clef` maintains a separate database of metadata, contaiing
- ruleset data, 
- passwords

If a user has 5M keystores, it should also be possible to have 5M passwords. Currently, this would probably not scale well. Although each password is individually encrypted in an aes-gcm container (so the entire thing doesn't need to be decrypted),  I suspect that it might be pretty slow to access one of them, since the whole thing is loaded into memory first. 

### Possible solutions

- Add a generic backend for database-backed keystore, where a somewhat generic database can be configured. The database should be able to answer queries about what addresses exist, and delivery encrypted keystore json. Users can then configure this with arbitrary SQL database, either locally or remote.  This has the upside that it's totally up to `clef` to maintain integrity and robustness of the database -- it will be up to the user to manage the database. 

- Add a non-generic database, e.g. leveldb or sqlite or something custom. If we do something custom, it's highly important that the db is robust. Database corruption, resulting in the loss of keystore data is not acceptable. 





Make `clef` scalable

### Describe the bug

The padding of the opcodes page looks off:
https://ethereum.org/en/developers/docs/evm/opcodes

### To reproduce

1. Go to https://ethereum.org/en/developers/docs/evm/opcodes
2. See margin/padding of main content

### Expected behavior

Should look same as other docs pages.

### Screenshots

Opcodes page:
![Image 2022-10-25 at 10 29 18 AM](https://user-images.githubusercontent.com/8097623/197817103-7ffd31ec-15f1-4a8f-a13d-3aa1638efaa5.jpg)

Normal page:
![Image 2022-10-25 at 10 29 35 AM](https://user-images.githubusercontent.com/8097623/197817128-bee6c3b8-2bfd-4c91-ab03-63582060394f.jpg)


### Desktop (please complete the following information)

Brave MacOS

### Smartphone (please complete the following information)

_No response_

### Additional context

Perhaps a result of https://github.com/ethereum/ethereum-org-website/pull/8332 ?

ethereum

Inconsistent padding/margin on docs pages

Simple renaming. If we have the correct fork names throughout, it makes sense to me that Merge -> Paris.

chore: Update the "Merge" fork name to "Paris" within the repo

https://github.com/ethereum/solidity/releases/tag/v0.8.23

Update framework tests and docs for solc 0.8.23

Thanks to the developers for this great software!

This is a "would be nice to have" feature request to add a flag to the JSON-RPC/GraphQL query input have Geth search for the events in reverse chronological order and only return the most recent log (or the batch from that block).

Unless I'm mistaken, at the moment it is only possible to construct queries that return all of the events for a given filter.

If you have a case where you only want the most recent event, but you don't know when it occurred, you still need to get back all of the events and filter (potentially not ideal on a client machine).

See also: 

[https://ethereum.stackexchange.com/questions/41976/how-to-get-only-latest-log-from-my-event](https://ethereum.stackexchange.com/questions/41976/how-to-get-only-latest-log-from-my-event)
[https://ethereum.stackexchange.com/questions/8699/how-to-get-only-latest-logged-event-via-web3-api](https://ethereum.stackexchange.com/questions/8699/how-to-get-only-latest-logged-event-via-web3-api
)

Thanks,

Lee


Feature Request: A query that returns the most recent event for a given filter.

**Is your feature request related to a problem? Please describe.**
Currently our markdown does not support syntax for mathematical expressions. Although these are not super frequent, having the ability to properly display mathematical expressions could expand our ability to convey certain concepts. I suspect we could use more math examples if we had the proper support for them. 

Surfaced while working through the new page related to proof-of-stake rewards and penalties. 

**Describe the solution you'd like**
https://github.blog/2022-05-19-math-support-in-markdown/
GitHub recently rolled out a similar feature, which can be used with `$` or `$$` delimiters. ie. $e^{i \pi} = -1$ instead of `e^(i*pi) = -1`
Not sure exactly what library they use.
Couple possible libraries
https://www.gatsbyjs.com/plugins/gatsby-remark-katex/
https://www.mathjax.org/

**Describe alternatives you've considered**
Just leave the markdown as is, and type all math examples with inline text. :-(

**Additional context**
The method chosen should be sure to support dark mode color themes.
Ideally text is still selectable, rather than rendered as an image. 
Ideally also support RTL languages, but not certain how that would play in.

Example of mathematic expressions being used: https://eth2book.info/altair/annotated-spec/#reward-and-penalty-calculations

**Want to contribute?**
We love contributions from the Ethereum community! Please comment on an issue if you're interested in helping out with a PR.


Mathematical expression support for markdown

The execution-spec-tests publish _compiled_ JSON tests as a GitHub release at https://github.com/ethereum/execution-spec-tests/releases/latest.

- [ ] Get the latest release and locally run the tests with `evmone-statetest` tool. Report any problems or failed tests.
- [ ] Extend existing state-tests CI job to also download and run these tests. CI config: https://github.com/ethereum/evmone/blob/v0.10.0/circle.yml#L432-L449.

Check execution-spec-tests

Again, filing this issue based on discussion in #555.  Currently Truffle doesn't support Solidity <0.4.9 because the (wrapped) compiler output doesn't give file paths, but rather just groups every contract under the empty path.  Over on #555, @cameel suggested it might be possible for `solc/wrapper` to repair this?  I certainly hadn't considered that possibility!  Well, just in case it is, I'm filing this issue as suggested. :)

Solidity <0.4.9 doesn't give file paths; is there any way for wrapper to repair this?

Currently we need to reimplement everything that beacon node is doing to measure the withdrawable epoch and time. It'll be good to have an API returning back informations like:

- exitEpoch
- withdrawableEpoch
- ...

If a validator is going to exit now. This can help building some applications. Validator Index will be the input.

withdrawable epoch measurement API

Add a LTO build to CI. We can check the performance of Release vs Release+LTO builds but previously difference where neglectable.
However, LTO build can reveal some C++ bugs.

In CMake IPO can be enabled with [`INTERPROCEDURAL_OPTIMIZATION`](https://cmake.org/cmake/help/latest/prop_tgt/INTERPROCEDURAL_OPTIMIZATION.html) property. The Hunter controlled dependencies should be build with IPO enabled too therefore a CMake toolchain file must be used.

CI: Add a LTO/IPO build

Now that we have benchmarks for EVMMAX precompiles we can experiment with different Montgomery multiplication algorithms. Currently we use [CIOS](https://github.com/ethereum/evmone/blob/v0.11.0/lib/evmmax/evmmax.cpp#L55-L83).

The [reference paper](https://www.microsoft.com/en-us/research/wp-content/uploads/1998/06/97Acar.pdf) we used have a summary of the complexity of each algorithm. However, these may not be directly applicable to small numbers like 256-bit. Check also what other projects are doing.

Optimize EVMMAX montgomery multiplication

Filing this issue based on discussion in #555.  Currently[0] Truffle repairs this (see [this Truffle PR](https://github.com/trufflesuite/truffle/pull/4363) for more info), but over on #555 @cameel suggested that perhaps `solc/wrapper` should be reparing this.  (And then the fix would apply to everyone, not just Truffle, and we could remove our code for repairing it.)  So, filing this issue asking for that.

[0]Well, OK, as of when I write this the fix isn't released yet, but it is merged...

Solidity <0.4.20 creates incorrect contracts output when are file paths with colon in them; could wrapper repair this?

### Describe the bug

wrong aligment:

 too much white space in cards (https://ethereum.org/en/what-is-ethereum/)
![Screenshot 2023-10-03 at 22 03 25](https://github.com/ethereum/ethereum-org-website/assets/100724231/6c3f5288-b370-43be-909b-baad8c85f59a)

expected design: (see https://ethereum.org/en/get-eth/)
![Screenshot 2023-10-04 at 16 46 53](https://github.com/ethereum/ethereum-org-website/assets/100724231/a15fb2de-bb9d-4cae-8905-e849e331096c)



### To reproduce

1. use mobile device
2.  Go to https://ethereum.org/en/what-is-ethereum/

### Expected behavior

see other comments

### Screenshots

_No response_

### Desktop (please complete the following information)

_No response_

### Smartphone (please complete the following information)

_No response_

### Additional context

_No response_

### Would you like to work on this issue?

- [ ] Yes
- [X] No

Wrong paddings on What is ethereum page (mobile)

### Describe the bug

Dates on event cards are not being formatted using intl locale.

### To reproduce

1. Go to https://ethereum.org/zh/community/events/
2. Notice date format in event cards compared to date at the top of the page.

### Expected behavior

Despite the contents of these cards not being translated into other languages, I would expect these dates to be rendered according to the locale.

The [`Intl.DateTimeFormat`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) should be used by passing the current locale and the date to render accordingly.

### Screenshots

<img width="866" alt="image" src="https://github.com/ethereum/ethereum-org-website/assets/54227730/7462d64f-361f-415b-9892-8e4b1a784ae7">


### Desktop (please complete the following information)

_No response_

### Smartphone (please complete the following information)

_No response_

### Additional context

_No response_

### Would you like to work on this issue?

- [ ] Yes
- [X] No

Incorrect intl number formatting

### Describe the bug

H4's on /staking pages appear to have grown in size to 36px from 20px.

### To reproduce

1. Go to https://ethereum.org/en/staking/#comparison-of-options
2. See size of H4's


### Expected behavior

This is what is was previously like (and would expect):

<img width="1731" alt="image" src="https://github.com/ethereum/ethereum-org-website/assets/54227730/e5a34abf-5048-4362-830e-4aafde240cde">


### Screenshots

Currently:

![image](https://github.com/ethereum/ethereum-org-website/assets/54227730/3f5794a6-327f-4602-bbf2-8268a2c46c62)


### Desktop (please complete the following information)

_No response_

### Smartphone (please complete the following information)

_No response_

### Additional context

@nloureiro or @konopkja if you could confirm this

### Would you like to work on this issue?

- [ ] Yes
- [X] No

H4 sizing on /staking page

#### System information

Geth version: `v1.10.16`
OS & Version: OSX
Commit hash: -

#### Expected behaviour

abigen produces a go wrapper

#### Actual behaviour

abigen errors out

#### Steps to reproduce the behaviour

Save this as Example.sol

```
// SPDX-License-Identifier: MIT

pragma solidity 0.8.6;

library Example {
  enum Field {
    F1
  }

  function example(Field x) public view {}
}
```

Run:
```
solc-select use 0.8.6
./abigen --pkg example --sol Example.sol
```

#### Backtrace

````
Fatal: Failed to generate ABI binding: unsupported arg type: Example.Field
````


Abigen fails with complex type as argument

use case:
i've created a password in my password manager and copypasted it into the cli, but i cannot be certain that it actually worked.
so for this particular and in general for reassurance reasons it would be a nice option if the tool allows to verify the password against a set of validator key files, or whatever gets encrypted with that during the process...

add a way to test the password

*To make our work more accessible and to foster more community collaboration, our team publishes an overview of our quarterly roadmap goals. See last quarter's roadmap here: #10666.*

**Greetings fellow Ethereans!**

[Our vision with ethereum.org](https://ethereum.org/en/about/) continues to be to create the best portal for Ethereum's growing community. We’re an educational resource focused on helping onboard millions of visitors to Ethereum each month. Here's a look at our major Q4 initiatives to advance this vision.

Quick point of clarification: ***this is the roadmap for [ethereum.org](http://ethereum.org/) the website, not Ethereum the protocol***. If you’re looking for the Ethereum roadmap, check out information on [upcoming network upgrades](https://ethereum.org/en/roadmap/) and learn more about [Ethereum governance](https://ethereum.org/en/governance/).

With that out of the way, let’s dive in.

## 🖊️ Writing cohort v2

The engagement with our May 2023 edition of the [ethereum.org](http://ethereum.org) writers' cohort was so impressive that we're excited to announce we'll be running a second cohort! Registration is already open, and the cohort starts on October 20th.

The writers' cohort is a 3-week online writing program for anyone interested in writing about Ethereum. During the cohort, participants will attend weekly workshops, publish articles on topics of their choice, and receive support and feedback from our global community.

[_Join the ethereum.org's writers cohort_](https://ethereumwriterscohort.carrd.co/)

## 🦄 Plan 2024 community acknowledgements

For the contributors 👀!

In Q4, we'll plan our contributor acknowledgement campaign for all of 2024, including different types of acknowledgements, different platforms we plan to use, tiered acknowledgements for different types of contributors, and a unified contributor campaign to further reward contributing to ethereum.org

## 🇹🇷 Devconnect prep

[Devconnect](https://devconnect.org/) is set to be the biggest Ethereum event in 2023, and the entire [ethereum.org](http://ethereum.org) team will be attending! This initiative will cover everything from ensuring we all arrive safely in Istanbul to creating swag for and organizing an ethereum.org event for contributors while we're there.

We hope many of our outstanding contributors will attend, and we'd love to see you there! If you plan to be at Devconnect, [give us a ping on Discord](http://ethereum.org/discord)!

## 📜 Redesign menu navigation

Our website's has grown to over 300 pages. The more pages that exist, the harder it is for users to navigate and find information.

We've noticed a few problems: a lack of user guidance, difficulty finding content in the subpages, difficulty finding new content, and visual inconsistency between menu items.

In Q4, we'll redesign the menu navigation to improve the user experience, with the goal of implementing the changes in early Q1.

## 🍁 Design system: content tabs and third-level navigation

Our Design System is an ongoing initiative started in 2022. As we move forward, we'll continue comprehensive breakdowns of our plans each quarter.

In Q4, our focus will be on:

- Redesigning our third-level navigation concurrently with the main navigation overhaul
- Streamlining the design of content tabs across the website

_We welcome your thoughts – we'll share our progress and seek feedback in our design channel on Discord. Want to get involved? [Join us on Discord!](http://ethereum.org/discord)_

## 👛 Find wallets design improvements

The Find Wallet page is a crucial component of our website, with a high traffic volume and an intricate UI/UX design. Due to its high impact, we will further improve its functionality and user experience in Q4 by:

- Rethinking the mobile experience, as this page receives the highest mobile traffic.
- Improving the wallet selection process for new users
- Reviewing filters and personas to reflect ecosystem developments

_[Join our Discord to get involved and see updates on the design changes](http://ethereum.org/discord)_

## 🌱 Seed phrase page

While we have content on wallets, password security, and accounts, we need better content explaining how seedphrases work.

These foundational topics can empower users to understand the importance of these words, why keeping them safe matters, and how to use them.

We'll write more detailed, technical information in the future, but for Q4, we'll focus on beginner-level content, including:

- Demystifying the terminology
- Illustrating how these words can generate multiple keys
- Clarifying that key generation adheres to a standard and alleviating concerns about longevity and transferability
- Highlighting common threats, behaviours to avoid, and strategies to bolster security

Want to learn more? We’ll share our brainstorming and work-in-progress in [our content channels on Discord](http://ethereum.org/discord)

## 📉 GitHub Zero!

During Q4, we will increase the time we, as the core team, spend reviewing GitHub issues and pull requests. The goal will be returning to maintenance mode we have outlined for [issues](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/github-issue-triage-process.md) and [pull requests](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/review-process.md).

Friendly reminder that we encourage input from the community [you're free to review and give input to any open issue or pull request](https://github.com/ethereum/ethereum-org-website/pulls).

## 🍴 Dencun Content Updates

The next major Ethereum upgrade, Dencun, is expected for a Q4 2023/Q1 2024 release. This upgrade will drastically reduce layer-2 fees via the Proto-Danksharding (EIP-4844) implementation.

In Q4, we will:

- Introducing content related to the upgrade
- Advising node operators to update their setups
- Educating users about the changes and their impact

## 🛣️ 2024 roadmapping and budget

2023 was a big year for ethereum.org, and we want to make 2024 an even bigger one. As part of this initiative, we'll devote time to planning out our roadmap and budget for 2024 by reflecting on what we've done, where we are, and where we want to go.

If you're interested in the longer-term vision of ethereum.org, [join our Discord](http://ethereum.org/discord). We'll plan our completed high-level plans with the community by the end of the year!

## 🕊️ Migrate to NextJS

A carry-over project from Q3, our goal is to transition our website from Gatsby to NextJS, completing the move in Q4.

A significant chunk of our Q4 efforts will be channelled towards testing and quality assurance of the migration. We'll be relying on the community to help us test for bugs and issues. [Join our Discord to help](http://ethereum.org/discord)!

## 🪐 Migrate Platform to Netlify

We currently use Gatsby Cloud for our weekly website builds and deployments. Unfortunately, Gatsby Cloud is being discontinued, with its services stopping on October 30th.

In Q4, we'll transition from Gatsby Cloud to Netlify. This will ensure our contributors continue to benefit from preview deploys on their pull requests and that we can continue to release new content weekly without interruption.

## 💯 Quizzes bug

In Q2, we launched our new and popular quiz hub.

Due to some technical details of how it was built, we can't add new quizzes to the hub. In this relatively small epic, we will refactor the quiz hub code to enable us to expand the quiz hub to include the 10+ new quizzes we've already written 🎉

Want to help? [Learn more in the GitHub issue.](https://github.com/ethereum/ethereum-org-website/issues/10887)


# How does that sound?

We always appreciate feedback on our roadmap - if there's something you think we should work on, please let us know! We welcome ideas and PRs from anyone in the community.

Get involved: [Learn more about contributing](https://ethereum.org/en/contributing/), [hit us up on Twitter](https://twitter.com/ethdotorg), or join the community discussions in [our Discord](https://discord.gg/CetY6Y4).

Q4 2023 ethereum.org product roadmap

The intent of this feature is to allow anyone to send to our crawler their node so we can crawl. Makes p2p discovery easier and faster.. This will require:

- an update on the UI to submit their node
- require API changes to validate that information
- crawler support to continuously crawl that info

Discover my node

The README.md is not very readable.
We can organize it better with a docs space to explain the technical details.


Add docs website

This should be in the form of providing fixtures, the JSON outputs from previous compiler versions, and comparing that against and expected translation.

At least the versions listed in https://github.com/ethereum/solc-js/blob/master/test/compiler.js#L643-L650 should be included.

Add proper unit tests to translate.js

Parallelize download of solc-bin versions and check against local cache before downloading.

Optimize download of solc and check against local cache before downloading

I tried running
`solcjs --standard-json`

and the following output was produced:

>  node:fs:208   
let mode = stats[1];  
^  
TypeError: Cannot read properties of undefined (reading '1')  
←[90m    at isFileType (node:fs:208:19)←[39m  
←[90m    at Object.readFileSync (node:fs:456:16)←[39m  
    at Object.<anonymous> (C:\Users\sriva\AppData\Roaming\npm\node_modules\←[4msolc←[24m\solcjs:128:18)  
←[90m    at Module._compile (node:internal/modules/cjs/loader:1101:14)←[39m  
←[90m    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)←[39m  
←[90m    at Module.load (node:internal/modules/cjs/loader:981:32)←[39m  
←[90m    at Function.Module._load (node:internal/modules/cjs/loader:822:12)←[39m  
←[90m    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)←[39m  
←[90m    at node:internal/main/run_main_module:17:47←[39m  

The "^" isn't correctly placed in the above text; it was just below "[" in "let mode = stats[1];"

What's wrong here? `solcjs --abi` and `solcjs --bin` work perfectly well.

`TypeError: Cannot read properties of undefined (reading '1')` in `solc.js` when passing the input for `--standard-json` via stdin

Point multiplications in that file could be sped up with wNAF. The relevant functions are annotated with TODO items.

Implement wNAF for point multiplications in crypto::engine::arkworks::endomorphism

Currently, field and struct names can be duplicated in a struct definition. For example, the below code is allowed,
 
```
pub struct Bar {
    pub x: i32
    
    pub fn x(self) -> i32 {
        return 0
    }
}
```

This can be error-prone; Unintentionally, users might write field access with the intention of a method call or vice versa.
So it would be better/safer to forbid this duplication.

Forbid field and method name duplication in struct definition

See https://github.com/firnprotocol/EIPs/blob/e7cfd688b622781ab20c0243253f9d330dc350fc/EIPS/eip-5630.md?plain=1#L156 as an example

(Note that if there isn't a space, then it isn't valid markdown)

New Lint: Space missing in a header

to accelerate the docker build this packages can be prebuilt and installled from ppa
boost version 1.79

compile libboost filesystem and system packages to ubuntu 20. ppas

See https://github.com/ethereum/EIPs/pull/5463

Add support for adoptable front matter attribute

_originally posted by @poojaranjan in https://github.com/ethereum/EIPs/issues/6131_

Disallow `Withdrawn` EIPs in the `requires:` header

Cut the repo https://github.com/winsvega/solidity.git 
to have only whats required to use lllc 

Simplify Solidity LLLC build

`ChaCha20Rng` does not currently implement `Zeroize`. It seems like there is no trivial way to implement it, so it either requires an upstream contribution or unsafe memory fiddling. Either way, this behavior should be implemented and used in `batch_contribution::derive_taus`. 

Make ChaCha20Rng zeroizable

@chriseth reports that search hits in our docs look like this in Google:
![image](https://user-images.githubusercontent.com/137030/178474001-f26cf55c-76ca-4346-a7ef-ce3e407bd094.png)

Here's what Googles's help says about this: [No page information in search results](https://support.google.com/webmasters/answer/7489871).

I'm pretty sure this has something to do with the [`robots.txt`](https://docs.soliditylang.org/robots.txt) changes we did some time ago #10898. The search result seems to be from `develop`, which our `robots.txt` block. We only allow `latest`, `v0.7.6` and latest release. The question is - why is `develop` still getting indexed (and appears in results before those other allowed versions) if we blocked it?

Ethereum Foundation

About

Team

Bounties

Jobs