diff --git a/docs/_navbar.md b/docs/_navbar.md index a828b46f..53376eea 100644 --- a/docs/_navbar.md +++ b/docs/_navbar.md @@ -1,3 +1,4 @@ * [Home](readme.md) * [Study Group](/eps/intro.md) +* [Protocol Wiki](/wiki/wiki-intro.md) * [Contribute](contributing.md) diff --git a/docs/_sidebar.md b/docs/_sidebar.md index 63c39818..4bac6d42 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -69,11 +69,12 @@ - Preconfirmations - [Preconfirmations](/wiki/research/Preconfirmations/Preconfirmations.md) - [Based Sequencing with Preconfs](/wiki/research/Preconfirmations/BasedSequencingPreconfs.md) + - [Light clients](/wiki/research/light-clients.md) - [Cryptography](/wiki/Cryptography/intro.md) - [ECDSA](/wiki/Cryptography/ecdsa.md) - [BLS](/wiki/Cryptography/bls.md) - [Keccak256](/wiki/Cryptography/keccak256.md) - - [Commitments] + - Commitments - [KZG](/docs/wiki/Cryptography/KZG.md) - [Post-Quantum Cryptography](/wiki/Cryptography/post-quantum-cryptography.md) - [Protocol Fellowship](/wiki/epf.md) @@ -82,5 +83,5 @@ - [GitHub Repository](https://github.com/eth-protocol-fellows/protocol-studies)
- +
diff --git a/docs/assets/css/custom.css b/docs/assets/css/custom.css index fa004e2f..1daa56f8 100644 --- a/docs/assets/css/custom.css +++ b/docs/assets/css/custom.css @@ -154,4 +154,216 @@ body .markdown-section { line-height: 1.3; font-size: 14px; } -*/ \ No newline at end of file +*/ + +/* + ################################ + || || + || 🎨 EPF.WIKI Theme || + || || + ################################ +*/ + +:root { + --base-background-color: #1c153b; + --sidebar-name-color: #ba9afd; + --sidebar-background: #190c39; + --sidebar-toggle-background: #190c39; + --navbar-root-color--active: #ba9afd; + --search-input-background-color: #2d1763; + --table-row-odd-background: #2d1763; + + /* blockquote*/ + --blockquote-background: #2d1763; + --blockquote-color: #fff; + --blockquote-border-color: #ba9afd; + + /* link */ + --link-color: #ba9afd; +} + +/* sidebar */ +li.file, +li.folder { + transition: all 0.3s ease-in-out; + padding: 8px 15px; + margin-bottom: 4px; +} +li.file p, +li.folder p { + margin: 0; +} + +li.folder.active, +li.folder:hover, +li.folder.open, +li.file.active, +li.file:hover, +li.file.open { + border-radius: 5px; + background: #2d1763; +} + +.app-sub-sidebar li.file, +.app-sub-sidebar li.folder { + padding: 0; + margin: 0; + animation: tabFade 0.5s; +} + +li.folder strong, +li.file strong { + padding: 10px 0; + display: block; + border-bottom: 1px dashed #a278ff; +} + +li.folder > ul > li.file { + padding: 0; +} +.sidebar-nav ul.app-sub-sidebar a { + border: none; + border-left: 4px solid #fff; + padding-left: 8px; +} + +.sidebar-nav ul.app-sub-sidebar li.active > a, +.sidebar-nav ul.app-sub-sidebar li a:hover { + border-color: #ba9afd; + text-decoration: none; + color: #ba9afd; + border-left: 4px solid #ba9afd; +} + +.sidebar .search .input-wrap { + padding: 8px 15px; + margin: 0; + border-radius: 50px; + border: 2px solid #6660b9; +} +.sidebar .search input[type="search"], +.sidebar .search input[type="search"]:focus { + background-color: #2d1763; + outline: none; + box-shadow: none; +} +.sidebar-nav a:hover { + text-decoration: none; +} +@keyframes tabFade { + 0% { + opacity: 0; + } + + to { + opacity: 1; + } +} +/* content */ +.markdown-section img { + border-radius: 8px; +} +.markdown-section h2 a::before, +.markdown-section h3 a::before, +.markdown-section h4 a::before, +.markdown-section h5 a::before, +.markdown-section h6 a::before { + color: #ba9afd; + margin-right: 5px; +} + +.app-nav li a { + color: #fff; + font-weight: bold; +} + +.sidebar-toggle .sidebar-toggle-button { + padding: 20px; + border-radius: 5px; + --sidebar-toggle-icon-height: 8px; + --sidebar-toggle-icon-stroke-width: 2px; + background: #6e52a9; +} + +@media only screen and (min-width: 768px) { + .sidebar-toggle .sidebar-toggle-button { + padding: 20px; + border-radius: 5px; + --sidebar-toggle-icon-height: 8px; + --sidebar-toggle-icon-stroke-width: 5px; + background: #6e52a9; + } + .sidebar-toggle span:nth-child(1) { + transform: rotate(-45deg); + } + + .sidebar-toggle span:nth-child(2) { + display: none; + } + + .sidebar-toggle span:nth-child(3) { + transform: rotate(45deg); + } + + .ready-fix.close .sidebar-toggle span:nth-child(1) { + transform: rotate(45deg); + } + + .ready-fix.close .sidebar-toggle span:nth-child(3) { + transform: rotate(135deg); + } +} + +.sidebar-toggle span { + transition: transform 0.5s ease-in-out; +} + +.btn-primary, +.markdown-section a.btn-primary { + border: none; + outline: none; + cursor: pointer; + text-align: center; + border-radius: 3rem; + background: #ba9afd; + padding: 0.75rem 1.5rem 0.85rem; + font-size: 1.13rem; + font-weight: 500; + line-height: 1; + color: #190c39; + margin: 10px 0; + display: inline-block; + text-decoration: none; +} + +.btn-primary::after { + display: inline-block; + margin-left: 4px; + font-size: 22px; + content: "➡"; +} +body .pagination-item-title, +body .pagination-item-label { + font-weight: bold; + color: #fff; + opacity: 1; +} + +.app-name-link { + display: flex; + align-items: center; /* Vertical align */ + justify-content: center; + font-weight: bold; + font-size: 25px; +} + +.logo { + display: inline; + width: 40px; + margin-right: 5px; +} + +.markdown-section table { + display: table; + width: 100%; +} diff --git a/docs/eps/intro.md b/docs/eps/intro.md index ec90e06f..bca7e631 100644 --- a/docs/eps/intro.md +++ b/docs/eps/intro.md @@ -25,26 +25,26 @@ The first part of the program consists of 6 sessions with introductions to high | Week # | Topic | Speaker | | ------------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------ | | [Week 1](/eps/week1.md) | Intro to EPS and Ethereum protocol | [Josh Davis](https://github.com/JoshDavisLight), [Mario Havel](https://github.com/taxmeifyoucan) | -| [Week 2](/epf/week2.md) | Execution Layer | [Lightclient](https://github.com/lightclient) | -| [Week 3](/epf/week3.md) | Consensus layer | [Alex Stokes](https://github.com/ralexstokes) | -| [Week 4](/epf/week4.md) | Testing and security | [Mario Vega](https://github.com/marioevz) | -| [Week 5](/epf/week5.md) | Roadmap and research | [Domothy](https://github.com/domothyb) | -| [Week 5](/epf/node_workshop.md) | Node workshop | [Mario](https://github.com/taxmeifyoucan) | +| [Week 2](/eps/week2.md) | Execution Layer | [Lightclient](https://github.com/lightclient) | +| [Week 3](/eps/week3.md) | Consensus layer | [Alex Stokes](https://github.com/ralexstokes) | +| [Week 4](/eps/week4.md) | Testing and security | [Mario Vega](https://github.com/marioevz) | +| [Week 5](/eps/week5.md) | Roadmap and research | [Domothy](https://github.com/domothyb) | +| [Week 5](/eps/node_workshop.md) | Node workshop | [Mario](https://github.com/taxmeifyoucan) | The second part of the program offers two distinct tracks focused on development and research with deeper dive into each domain. | Week #, track | Topic | Speaker | | ------------------------------------------- | ----------------------------- | -------------------------------------------------------------------------------------- | -| [Week 6 Development](/epf/week6-dev.md) | Consensus and Execution specs | [Hsiao-Wei Wang](https://github.com/hwwhww), [Sam Wilson](https://github.com/SamWilsn) | -| [Week 6 Research](/epf/week6-research.md) | Sharding and DAS | [Dankrad Feist](https://github.com/dankrad) | -| [Week 7 Developsment](/epf/week7-dev.md) | Execution client architecture | [Dragan Pilipovic](https://github.com/dragan2234) | -| [Week 7 Research](/epf/week7-research.md) | Verkle trees | [Josh Rudolf](https://github.com/jrudolf) | -| [Week 8 Development](/epf/week8-dev.md) | Consensus client architecture | [Paul Harris](https://github.com/rolfyone) | -| [Week 8 Research](/epf/week8-research.md) | MEV and censorship | [Barnabe Monnot](https://github.com/barnabemonnot) | -| [Week 9 Development](/epf/week9-dev.md) | Devops and testing | [Parithosh](https://github.com/parithosh) | -| [Week 9 Research](/epf/week9-research.md) | Purge and Portal Network | [Piper Merriam](https://github.com/pipermerriam) | -| [Week 10 Development](/epf/week10-dev.md) | EL precompiles | [Danno Ferrin](https://github.com/shemnon) | -| [Week 10 Research](/epf/week10-research.md) | SSF and PoS Upgrades | [Francesco D’Amato](https://github.com/fradamt) | +| [Week 6 Development](/eps/week6-dev.md) | Consensus and Execution specs | [Hsiao-Wei Wang](https://github.com/hwwhww), [Sam Wilson](https://github.com/SamWilsn) | +| [Week 6 Research](/eps/week6-research.md) | Sharding and DAS | [Dankrad Feist](https://github.com/dankrad) | +| [Week 7 Development](/eps/week7-dev.md) | Execution client architecture | [Dragan Pilipovic](https://github.com/dragan2234) | +| [Week 7 Research](/eps/week7-research.md) | Verkle trees | [Josh Rudolf](https://github.com/jrudolf) | +| [Week 8 Development](/eps/week8-dev.md) | Consensus client architecture | [Paul Harris](https://github.com/rolfyone) | +| [Week 8 Research](/eps/week8-research.md) | MEV and censorship | [Barnabe Monnot](https://github.com/barnabemonnot) | +| [Week 9 Development](/eps/week9-dev.md) | Devops and testing | [Parithosh](https://github.com/parithosh) | +| [Week 9 Research](/eps/week9-research.md) | Purge and Portal Network | [Piper Merriam](https://github.com/pipermerriam) | +| [Week 10 Development](/eps/week10-dev.md) | EL precompiles | [Danno Ferrin](https://github.com/shemnon) | +| [Week 10 Research](/eps/week10-research.md) | SSF and PoS Upgrades | [Francesco D’Amato](https://github.com/fradamt) | ### Streams and recordings @@ -86,7 +86,7 @@ For our weekly meetings, we are using a self-hosted FOSS platform Jitsi. Even th - **Will I learn to develop applications on the Ethereum blockchain?** - No. This program is not focused on Solidity or development of decentralized applications. - **When does it start and is the duration?** - - Program will start in February 2024 and continue for 10 weeks, finishing by end of April. + - The program ran from February 2024 and continued for 10 weeks, concluding by the end of April. - **Am I automatically accepted to EPF after attending EPFsg** - No. The study group is a great way to prepare for EPF, but it doesn't guarantee anything. However, EPF is a permissionless program, so you can always participate. - **Where is the study group located?** diff --git a/docs/index.html b/docs/index.html index df52dab1..791c3f92 100644 --- a/docs/index.html +++ b/docs/index.html @@ -33,7 +33,6 @@ href="https://cdn.jsdelivr.net/npm/docsify-themeable@0/dist/css/theme-simple-dark.css"> - @@ -111,7 +110,7 @@ } - + @@ -177,7 +176,7 @@ window.$docsify = { // GENERAL SETTINGS // ----------------------------------------------------------------- - name: 'Protocol Wiki', + name: ' Protocol Wiki', homepage: 'readme.md', loadSidebar: !(getURLParameterByName(['standalone', 'embedded']) || standalone || false), loadNavbar: !(getURLParameterByName(['standalone', 'embedded']) && !(getURLParameterByName('navbar')) || standalone && !navbar ||false), @@ -333,7 +332,7 @@ } else { url = gitLinkRepoURL + '/blob/main/docs/' + vm.route.file } - var editHtml = '[:memo:' + editThisPageLinkText + '](' + url + ')\n' + var editHtml = ` :memo: ${editThisPageLinkText}` if ((!(getURLParameterByName('hidegitlink'))) && (!!gitLinkRepoURL)) { return html + '
' + '\n\n' + editHtml diff --git a/docs/wiki/CL/cl-clients.md b/docs/wiki/CL/cl-clients.md index 87c9c573..fe27a406 100644 --- a/docs/wiki/CL/cl-clients.md +++ b/docs/wiki/CL/cl-clients.md @@ -161,6 +161,10 @@ Teku also provides a slashing protection mechanism, especially in the case where ## Clients in development +### Caplin + +A consensus client embedded in Erigon. + ### Grandine Originally a proprietary client in Rust, recently became open source diff --git a/docs/wiki/EL/clients/reth.md b/docs/wiki/EL/clients/reth.md index cc61a4bc..b5c0218c 100644 --- a/docs/wiki/EL/clients/reth.md +++ b/docs/wiki/EL/clients/reth.md @@ -24,8 +24,55 @@ The image represents a rough component flow of Reth's architecture: - **BlockchainTree**: When we are nearing the end of the chain during the syncing process, we transition to the blockchain tree. The synchronization occurs close to the tip, when state root validation and execution take place in memory. - **Database**: When a block gets canonicalized, it is moved to the database - **Provider**: An abstraction over database that provides utility functions to help us avoid directly accessing the keys and values of the underlying database. -- **Downloader**: Retrieves blocks and headers using peer-to-peer(P2P) networks. This tool is utilized by the pipeline during its initial two stages and by the engine in the event that it need to bridge the gap at the tip. +- **Downloader**: Retrieves blocks and headers using peer-to-peer (P2P) networks. This tool is utilized by the pipeline during its initial two stages and by the engine in the event that it need to bridge the gap at the tip. - **P2P**: When we approach the tip, we transfer the transactions we have read over P2P to the transaction pool. - **Transaction Pool**: Includes DDoS mitigation measures. Consists of transactions arranged in ascending order based on the gas price preferred by the users. - **Payload Builder**: Extracts the initial n transactions in order to construct a fresh payload. - **Pruner**: Allows us to have a full node.Once the block has been canonicalized by the blockchain tree, we must wait for an additional 64 blocks for it to reach finalization. Once the finalization process is complete, we can be certain that the block will not undergo reorganization. Therefore, if we are operating a full node, we have the option to eliminate the old block using the pruner. + +## Storage + +Reth primarily utilizes the mdbx database. In addition, it offers several valuable abstractions that enhance its underlying database by enabling data transformation, compression, iteration, writing, and querying functionalities. These abstractions are designed to allow reth the option to change its underlying DB, mdbx, with minimal modifications to the existing storage abstractions. + +**Codecs** + +This [crate](https://github.com/paradigmxyz/reth/tree/main/crates/storage/codecs) enables the creation of diverse codecs for various purposes. The primary codec utilized in this context is the [Compact trait](https://github.com/paradigmxyz/reth/blob/6d7cd53ad25f0b79c89fd60a4db2a0f2fe097efe/crates/storage/codecs/src/lib.rs#L43), which enables the compression of data, such as unsigned integers by compressing their leading zeros, as well as structures such as access-lists, headers etc. + +**DB Abstractions** + +The [database trait](https://github.com/paradigmxyz/reth/blob/e158542d31bf576e8a6b6e61337b62f9839734cf/crates/storage/db/src/abstraction/database.rs#L12) is the fundamental abstraction that provides either read only or read/write access to transactions in the low-level database. + +The [cursor](https://github.com/paradigmxyz/reth/blob/e158542d31bf576e8a6b6e61337b62f9839734cf/crates/storage/db/src/abstraction/cursor.rs#L13) enables iteration over the values in the database and offers a swift method for retrieving transactions or blocks. It is particularly useful when calculating merkle roots, as sequential value access is significantly faster than random seeking. In addition, if we have a large amount of data to write, sorting and writing it is much faster. The cursor allows us to optimize our approach by providing convenient functions for writing either sorted or unsorted data. + +**Tables** + +| Table | Key | Value | Description | +| -------------------------- | ----------------------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| CanonicalHeaders | BlockNumber | HeaderHash | Stores block number indexed by header hash | +| HeaderTerminalDifficulties | BlockNumber | CompactU256 | Is responsible for storing the total difficulty value obtained from a block header. Although it is commonly employed in proof-of-work systems, it is currently not in use. | +| HeaderNumbers | BlockHash | BlockNumber | This is a utility table, it stores block number associated with a header. | +| Headers | BlockNumber | Header | Stores header bodies. | +| BlockBodyIndices | BlockNumber | StoredBlockBodyIndices | Stores block indices that contains indexes of transaction and the count of them. This allows us to determine which transaction numbers are included in the block. | +| BlockOmmers | BlockNumber | StoredBlockOmmers | Stores the uncles/ommers of the block, which are the side blocks that got included (used in proof-of-work) | +| BlockWithdrawals | BlockNumber | StoredBlockWithdrawals | Stores the block withdrawals. | +| Transactions | TxNumber | TransactionSignedNoHash | Here the transaction body is stored indexed by the ordinary transaction number. This information includes the total number of transactions and the number of transactions that were executed. Furthermore, it enables us to effortlessly retrieve a solitary transaction. | +| TransactionHashNumbers | TxHash | TxNumber | Stores the transaction number indexed by the transaction hash. | +| TransactionBlocks | TxNumber | BlockNumber | Stores the mapping of the highest transaction number to the blocks number. Allows us to fetch the block number for a given transaction number. | +| Receipts | TxNumber | Receipt | Stores transaction receipts indexed by transaction number. | +| Bytecodes | B256 | Bytecode | Compiles and stores the bytecode of all smart contracts. There will be multiple accounts with identical bytecode. Therefore, it is necessary to implement a reference counting pointer. | +| PlainAccountState | Address | Account | Stores the current state of an [Account](https://github.com/paradigmxyz/reth/blob/fb960fb3e45e11c24125ccb4bd93f2e2e21ce271/crates/primitives/src/account.rs#L15), the plain state, indexed by the Account address. The plain state is updated during the execution stage. | +| PlainStorageState | Address , SubKey = B256 | StorageEntry | Stores the current value of a storage key and the sub-key is the hash of the storage key. Concerning sub-keys: mdbx allows us to dup table (duplicate values inside tables) which can lead a faster access to some values. | +| AccountsHistory | ShardedKey
| BlockNumberList | Stores pointers to the block changesets that contain modifications for each account key. Each account is associated with a record of modifications, represented as a list of blocks. For example, if we want to retrieve the account balance at block 1 million, we need to determine the next block where the account was modified. If the next modification occurs at block number 1 million and 1, we need to fetch the set of changes for that account from the tables below. | +| | +| StoragesHistory | StorageShardedKey | BlockNumberList | Stores pointers to block number changeset with changes for each storage key. This allows us to index the change sets and find the change that happened in the history | +| AccountChangeSets | BlockNumber, SubKey = Address | AccountBeforeTx | The state of an account is stored prior to any transaction that alters it, such as when the account is created, self-destructed, accessed while empty, or when its balance or nonce is modified. Therefore, for each block number. Therefore, we possess the previous values for each block and account address. | +| StorageChangeSets | BlockNumberAddress , SubKey = B256 | StorageEntry | Preserves the state of a storage prior to a specific transaction altering it. Therefore, for each block number, account address and sub-key as the storage key, we can obtain the previous storage value. The execution stage modifies both this table and the one above it. These tables are used for the merkle trie calculations, which require the values to be incremental. They are also used for any history tracing performed by the JSON-RPC API. | +| HashedAccounts | B256 | Account | Stores the current state of an account indexed by keccak256(Address). This table is in preparation for merkleization and calculation of state root. This and the table below are used by the merkle trie, for the first calculation of the merkle trie we need sorted hashed addresses | +| HashedStorages | B256, SubKey = B256 | StorageEntry | Stores the current storage values indexed by keccak256(Address) and the sub-key as the hash of storage key keccak256(key). Like above useful for merkleization as the hashed addresses/keys are sorted. | +| AccountsTrie | StoredNibbles | StoredBranchNode | Stores the current state's Merkle Patricia Tree. | +| StoragesTrie | B256 , SubKey = StoredNibblesSubKey | StorageTrieEntry | From HashedAddress => NibblesSubKey => Intermediate value. This and the above table stores the nodes needed for merkle trie calculation | +| TransactionSenders | TxNumber | Address | Stores the transaction sender for each transaction. It is needed to speed up execution stage and allows fetching the signer without doing the computationally expensive transaction signer recovery | +| StageCheckpoints | StageId | StageCheckpoint | Stores the highest synced block number and stage-specific checkpoint of each stage. | +| StageCheckpointProgresses | StageId | Vec | Stores arbitrary data to keep track of a stage first-sync progress. This and the above table allows us to know where the stage stopped and to determine what to do next. | +| PruneCheckpoints | PruneSegment | PruneCheckpoint | Records the maximum pruned block number and the pruning mode for each segment of the pruning process. This enables us to determine the extent to which we have pruned our data, involving the elimination of change sets and their corresponding indexes to eliminate historical data, leaving only the most recent data to be retrieved i.e. fetching the tip. | +| VersionHistory | u64 | ClientVersion | Stores the history of client versions that have accessed the database with write privileges indexed by unix timestamp seconds. | diff --git a/docs/wiki/EL/el-clients.md b/docs/wiki/EL/el-clients.md index 19e062f2..dcdb9db4 100644 --- a/docs/wiki/EL/el-clients.md +++ b/docs/wiki/EL/el-clients.md @@ -28,9 +28,13 @@ Developed in .NET Developed by Paradigm, recently considered stable +### Nimbus EL + +Execution client developed by Nimbus team as an addition to their Nim CL work. + ### Silkworm -Modular C++ implementation by Erigon team +Modular C++ implementation by Erigon team. Also called Erigon++. ### JS Client diff --git a/docs/wiki/research/light-clients.md b/docs/wiki/research/light-clients.md index e69de29b..e282d919 100644 --- a/docs/wiki/research/light-clients.md +++ b/docs/wiki/research/light-clients.md @@ -0,0 +1,33 @@ +# Light Clients + +> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it. + +Ethereum users are connecting to the network using an execution client RPC. This allows them to interact with the network, read balances, submit transactions, etc. Running the client and verifying the current state can be a demanding task requiring hundreds of GBs storage space, bandwidth and computation. Most wallets default to using a third party API to connect to the network without verifying the provided data. + +The idea of a light client is to enable trustless access to the network without overhead of running a full node. Light client is a general term for this concept but the actual approach is using different designs. There are multiple kinds of light clients, some in production, some still being researched and developed. + +- Verifying EL RPC data using Beacon root from a CL client +- Stateless clients +- LES protocol +- Portal network + +## RPC proxy light client + +This sort of light clients connect to an RPC provider and improves the security by verifying responses using a proof from an independent Beacon Node. It's basically an RPC proxy or a middleware which ensures that data from the provider are valid. +It improves the trust model of a wallet/service connected to a third party RPC but doesn't act as a node in the network. With this light client approach, users still need to connect to some RPC provider, a centralized entity. + +Clients communicating in the network over p2p protocol don't have specific functions for specific pieces of data like with RPC. They can get current tip from the peer, request historical blocks, etc. And to verify them, they also need connection to a consensus client. There is no way to request balance of an address over p2p, only download blocks/state, verify and find it yourself. With this approach, we basically arrive at the behavior of a normal node in the network. + +The implementation of the RPC verifying 'light client' is for example [Helios](https://github.com/a16z/helios) or [Kevlar](https://github.com/lightclients/kevlar). User can run them as a proxy between an app/wallet and their rpc provider. They offer a default connection to a public beacon node so the chance that both of these providers lie in the same exact way is minimal. There was a [project trying to implement the CL p2p in Helios](ttps://github.com/eth-protocol-fellows/cohort-three/blob/master/projects/helios-cl-p2p.md) in order to use it directly with cl libp2p instead of relying on a third party Beacon API. + +## Stateless clients + +Using witnesses gossiped over p2p network to verify the data without full state. + +## Portal Network + +Portal creates an overlay network which guarantees data integrity probabilistically. + +## LES + +Light client mode pioneered by Geth enables to run a node in light config which subscribes to les p2p protocol. The node doesn't download the entire chain, only downloads the latest data from other nodes serving les. The full node needs to be configured to provide les data, it's not a default option. Therefore there are not enough les providers in the network to enable using geth in light mode reliable. \ No newline at end of file diff --git a/notes/Week 10 EPFsg Research Track - Fork Choice.pdf b/notes/Week 10 EPFsg Research Track - Fork Choice.pdf new file mode 100644 index 00000000..8a3441a9 Binary files /dev/null and b/notes/Week 10 EPFsg Research Track - Fork Choice.pdf differ diff --git a/wordlist.txt b/wordlist.txt index 30879bae..82a4dee4 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -5,6 +5,7 @@ accelerometer ACD ACL addons +aggregative Aleth allowfullscreen amidst @@ -20,6 +21,7 @@ ASE Assche Assertoor assignees +atleast atomicity Attacknet attester @@ -66,8 +68,10 @@ Buterin Buterin's bypassability bytecode +bytecodes calldata canonicalized +Caplin Carb cartelization Casper @@ -78,6 +82,8 @@ centralisation centric chainId Challanges +changeset +changesets Charmes cli CLRS @@ -85,11 +91,14 @@ cmd CoC codebase codebases +codec CODECOPY +codecs coinbase commoditized Composability composable +computable config congestions Consensys @@ -148,6 +157,7 @@ Dracorn Dragan Driscoll DSA +dup DVT dx EB @@ -253,6 +263,7 @@ Grandine Guillaume hackmd Hager +HashedStorages Herc’s hoc Holesky @@ -264,6 +275,7 @@ Hulsing Hyperledger Hyperplonk ics +IETF iframe ify impera @@ -281,6 +293,7 @@ intermediation interop IOP IPC +IRTF ISA Jitsi js @@ -294,6 +307,7 @@ keccak Keccak's keecak KEM +keystore Kira Kleppmann Koblitz @@ -336,12 +350,14 @@ mem Mempool Menezes merkelizing +merkle Merkle Merkleization Merkleize MEV mevboost Michaël +middleware minimalistic Mitigations mload @@ -381,6 +397,8 @@ Odayan OFAC Offchain offsites +ommer +ommers onboarding onchain Oorschot @@ -485,6 +503,7 @@ runtime scalability scalable schemas +Schnorr Schocken Schwabe SECG @@ -493,8 +512,10 @@ SELFDESTRUCT Sepolia sexualized SHA +Shacham shadowfork Shafu +ShardedKey sharding ShareAlike Shead @@ -526,6 +547,9 @@ StateDB stateful stateRoot stf +StorageShardedKey +StoragesHistory +StoragesTrie StreamEth subnets suboptimal @@ -561,6 +585,7 @@ trustlessly trustlessness TrustLook TSTORE +Tx txpool txs unaggregated @@ -568,16 +593,19 @@ Unbundling underbrace Unformatted unguessable +unix upstreamed utils UTXOs UX Vadim validator +validator's validators Vanstone VB's VDFs +Vec verifications verifier verifiers @@ -607,24 +635,4 @@ zk zkEVMs ZKSNARK ZKSNARKs -Schnorr -IETF -IRTF -Shacham -aggregative -atleast -computable -keystore -validator's -verifications -CLRS -Endian -Noam -Pyrmont -Goerli -financials -testnets -Hotz -linearizer -tinygrad Zksync