Roadmap content #9241
Roadmap content #9241
Conversation
github-actions
bot
added
content 🖋️
konopkja
requested review from
samajammin,
wackerow,
corwintines,
pettinarip and
minimalsm
as code owners
There was a problem hiding this comment.
@jmcook1186 Well done! This was a great read. Left a bunch of small code suggestions and things we need to tidy up, but overall I thought this read very well with good flow to the content.
One thing we'll need to do is set up redirects for the /upgrades/ paths that were removed.
Great job!
Co-authored-by: Paul Wackerow <[email protected]>
Co-authored-by: Paul Wackerow <[email protected]>
|
@jmcook1186 I think you meant to link this PR to this issue? #9242 |
|
|
||
| State expiry is still in the research phase and not yet ready to ship. State expiry may well happen later than stateless clients and history expiry because those upgrades make large state sizes easily manageable for the majority of validators. | ||
|
|
||
| **Further reading** |
There was a problem hiding this comment.
@konopkja I think you raised this already, but corect me if I'm wrong. We shouldn't have further reading sections contained within individual headings (with the exception of within collapsable cards).
I'd move these all to the end
|
|
||
| Users that run their own nodes do not have to trust third parties to provide them truthful data, and they can interact quickly, privately and permissionlessly with the Ethereum blockchain. However, right now running a node requires some technical knowledge and substantial disk space, meaning many people choose to trust intermediaries instead. There are several upgrades that will make running nodes far easier and far less resource intensive. The way data is stored will be changed to use a more space-efficient structure known as a **Verkle Tree**. Also, with [statelessness](/roadmap/statelessness) or [data expiry](/roadmap/statelessness/#data-expiry), Ethereum nodes will not need to store their own copy of the entire Ethereum state data, drastically reducing hard disk space requirements. Light nodes will offer many of the benefits of running a full node but able to run easily on mobile phones or inside simple browser apps. | ||
|
|
||
| <ButtonLink variant="outline-color" to="/roadmap/verkle-trees/">Read about Verkle trees</ButtonLink> |
There was a problem hiding this comment.
I don't think button links should break sections like this..
cc: @konopkja
src/content/roadmap/scaling/index.md
Outdated
| Ethereum is scaling through [rollups](/layer-2/#rollups), which batch transactions together and send the output to Ethereum. Even though rollups are up to eight times less expensive than Ethereum Mainnet, it's possible to optimize rollups further to reduce costs for end users. Rollups also rely on some centralized components that developers can remove as the rollups mature. | ||
|
|
||
| <InfoBanner mb={8}> | ||
| <h4 style="margin-top: 0">Transaction costs</h4> |
There was a problem hiding this comment.
Not blocking, but this creates incorrect heading order by using an H4 here and is an accessibility issue.
cc: @corwintines
| template: roadmap | ||
| --- | ||
|
|
||
| Ethereum is scaling through [rollups](/layer-2/#rollups), which batch transactions together and send the output to Ethereum. Even though rollups are up to eight times less expensive than Ethereum Mainnet, it's possible to optimize rollups further to reduce costs for end users. Rollups also rely on some centralized components that developers can remove as the rollups mature. |
There was a problem hiding this comment.
Curious why /layer-2/#rollups and not just /layer-2/ here? Aren't all layer 2s under current definition rollups?
There was a problem hiding this comment.
to get people straight to the definition of rollup rather than having to skip through the introductory content
|
|
||
| ## Routes to SSF {#routes-to-ssf} | ||
|
|
||
| <ExpandableCard title= "Why can't we have SSF today?" eventCategory="/roadmap/single-slot-finality" eventName="clicked Why can't we hear SSF today?"> |
There was a problem hiding this comment.
I'm not sure why this is a card instead of a section/sub-section?
Co-authored-by: Joshua <[email protected]>
| summaryPoints: | ||
| - Understand why account abstraction will make Ethereum easier to use | ||
| - Learn about upcoming changes to how users will interact with Ethereum | ||
| - Read why account abstraction will help users to secure their assets |
There was a problem hiding this comment.
agree with the suggestion from @minimalsm , those should already state the outcome
| ## Current progress {#current-progress} | ||
|
|
||
| Smart contract wallets are already available, but more upgrades are required to make them as decentralized and permissionless as possible. EIP-4337 is a mature proposal that does not require any changes to Ethereum's protocol, so it is possible that this could be implemented quickly. However, upgrades that alter Ethereum's protocol are currently not in active development, so those changes may take much longer to ship. It is also possible that account abstraction is achieved well enough by EIP-4337 that no protocol changes are ever required. |
There was a problem hiding this comment.
@jmcook1186 "current progress" information is critical information and should be also presented on the main subpages. I would suggest moving this out of the dev docs there on all pages or including in on both.
There was a problem hiding this comment.
ok i added current progress summaries to the main subpages - lmk what you think
There was a problem hiding this comment.
Talked with @jmcook1186 @konopkja @minimalsm, this seems good to go for v1 MVP
Description
draft PR containing in-development protocol roadmap content.
Related Issue
#8532
#9242