-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EIP: P2P History Network #8630
base: master
Are you sure you want to change the base?
Conversation
File
|
EIPS/eip-template.md
Outdated
@@ -0,0 +1,375 @@ | |||
--- | |||
eip: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eip: | |
eip: 7719 |
Assigning next sequential EIP/ERC/RIP number.
Please also update the filename.
EIPS/eip-template.md
Outdated
title: P2P History Network | ||
description: Instead of every fullnode storing all the block history headers, transactions, and receipts distribute them amongst all nodes. To maintain the availability but lowering the storage requirements for all. | ||
author: Kolby ML (@KolbyML) | ||
discussions-to: https://ethereum-magicians.org/t/add-eip-p2p-history-network/20231 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussions-to: https://ethereum-magicians.org/t/add-eip-p2p-history-network/20231 | |
discussions-to: https://ethereum-magicians.org/t/eip-7719-p2p-history-network/20231 |
EIPS/eip-7719.md
Outdated
|
||
With lightweight sync strategies based on the PoS weak subjectivity assumption, which was possible after the merge. Storing all the block history was no longer required to sync and played a centralizing force increasing the storage requirements and sync times to participate in the Ethereum Network. | ||
|
||
Instead of each Ethereum node storing a full copy of the block history, what if this burden was divided amongst all nodes enabling each node to store a fraction of the blocks, but having access to all historical blocks as a collective lowering the cost for everybody, well maintaining the current JSON-RPC interfaces. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of each Ethereum node storing a full copy of the block history, what if this burden was divided amongst all nodes enabling each node to store a fraction of the blocks, but having access to all historical blocks as a collective lowering the cost for everybody, well maintaining the current JSON-RPC interfaces. | |
Instead of each Ethereum node storing a full copy of the block history, what if this burden was divided amongst all nodes enabling each node to store a fraction of the blocks, but having access to all historical blocks as a collective lowering the cost for everybody, while maintaining the current JSON-RPC interfaces. |
EIPS/eip-7719.md
Outdated
Look up are optimized for minimal lookup and single content per lookup. Models for doing bulk downloads of block history are being researched, for the majority of post [EIP-4444](./eip-4444.md) optimizing for faster single block look up times is considered more important. | ||
|
||
For pre-merge headers the embedded accumulator of [EIP-7643](./eip-7643.md) will be used, for merge till capella `HistoricalRootsBlockProof` the frozen accumulator in the beacon state will be used, but can be embedded in the client as well. For Capella onwards minus 8192 blocks `HistoricalSummariesBlockProof` the accumulator in the beacon state will be used. Well the EL client should already be aware of the latest 8192 blocks. A EIP to spec out these post merge validation path may be made |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try to write your proposal as if it were already final. It's always weird when stuff like "will be" and "should be" sneaks into final proposals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please include a license under which we can redistribute this PDF, or link to it externally. You can use the CSL-JSON format described in EIP-1:
Some text somewhere that needs a citation. [^1]
[^1]:
```csl-json
{
"publisher-place": "Berlin, Heidelberg",
"abstract": "We describe a peer-to-peer distributed hash table with provable consistency and performance in a fault-prone environment. Our system routes queries and locates nodes using a novel XOR-based metric topology that simplifies the algorithm and facilitates our proof. The topology has the property that every message exchanged conveys or reinforces useful contact information. The system exploits this information to send parallel, asynchronous query messages that tolerate node failures without imposing timeout delays on users.",
"author": [
{
"given": "Petar",
"family": "Maymounkov"
},
{
"given": "David",
"family": "Mazi\u00e8res"
}
],
"container-title": "Peer-to-Peer Systems",
"editor": [
{
"given": "Peter",
"family": "Druschel"
},
{
"given": "Frans",
"family": "Kaashoek"
},
{
"given": "Antony",
"family": "Rowstron"
}
],
"type": "paper-conference",
"DOI": "10.1007/3-540-45748-8_5",
"id": "10.1007/3-540-45748-8_5",
"citation-key": "10.1007/3-540-45748-8_5",
"ISBN": "978-3-540-45748-0",
"URL": "https://www.scs.stanford.edu/~dm/home/papers/kpos.pdf",
"issued": {
"date-parts": [
[
2002
]
]
},
"page": "53-65",
"publisher": "Springer Berlin Heidelberg",
"title": "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric",
"custom": {
"additional-urls": [
"https://link.springer.com/chapter/10.1007/3-540-45748-8_5",
"https://users.cs.utah.edu/~stutsman/cs6963/public/papers/kademlia.pdf"
]
}
}
```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PDF is no longer included directly in the EIP, because now we can link directly to the ethereum/portal-network-specs
let me know what the best steps forward is on this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PDF is no longer included directly in the EIP, because now we can link directly to the ethereum/portal-network-specs
let me know what the best steps forward is on this
@SamWilsn ready for another look |
The commit 64aa993 (as a parent of 05a5276) contains errors. |
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment/question as on #8629.
This eip is a draft for the Portal History Network. A P2P network for historical data which is referenced in Ethereum's roadmap