diff --git a/docs/_sidebar.md b/docs/_sidebar.md index 8c963401..ba1682a0 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -63,6 +63,7 @@ - [eODS](/wiki/research/eODS.md) - [PeerDAS](/wiki/research/peerdas.md) - [FCR](/wiki/research/FCR/FCR.md) + - [Stateless](/wiki/research/stateless/stateless.md) - [History Expiry](/wiki/research/history-expiry/history-expiry.md) - Preconfirmations - [Preconfirmations](/wiki/research/Preconfirmations/Preconfirmations.md) diff --git a/docs/wiki/research/img/stateless/state-collapse.png b/docs/wiki/research/img/stateless/state-collapse.png new file mode 100644 index 00000000..5339ddac Binary files /dev/null and b/docs/wiki/research/img/stateless/state-collapse.png differ diff --git a/docs/wiki/research/img/stateless/theVerge.png b/docs/wiki/research/img/stateless/theVerge.png new file mode 100644 index 00000000..7edb7d60 Binary files /dev/null and b/docs/wiki/research/img/stateless/theVerge.png differ diff --git a/docs/wiki/research/stateless/stateless.md b/docs/wiki/research/stateless/stateless.md new file mode 100644 index 00000000..5c1f0b08 --- /dev/null +++ b/docs/wiki/research/stateless/stateless.md @@ -0,0 +1,258 @@ +**Statelessness** is a concept that could be applied in many other fields, not only in Ethereum. + +For Ethereum, however, it will become essential in the coming years. ⚠️ + +# Idea of statelessness + +The idea of statelessness comes from an **unresolved problem** caused by the **continuous growth** of the Ethereum state. +If we want Ethereum to stay **decentralized**, we must not allow the state to **keep growing**, because that would mean that only **large clients** could **run it**, while **smaller ones** would **run out of disk space**. + +> A visual representation of the number of active nodes, illustrating the long-term impact of ignoring to address ongoing state growth: + +![stateless colapse](../img/stateless/state-collapse.png) + +In the case of **unaddressed continuous state growth**, even the security of the entire network and the Ethereum ecosystem would be called into question. + +So we need to find an effective solution. + +Either we introduce expiry for old and unpaid state, or we introduce a concept that allows a node to perform validation, block production, and attestation in the network without requiring it to store the whole Ethereum state. + +> If statelessness enables EL clients to run without storing the state on disk, +> then they can be run on: +> - a laptop, +> - a phone, +> - a Raspberry Pi, +> - or even in a browser (theoretically). +> +> and decentralization is not compromised. + +Stateless principle solves the problem, but it opens a new question: **Who is going to keep the state?** + +## Current state + +Currently, the state is stored in a **Merkle tree**, and only a **small portion** of the state is **read/written** in **each block**. +However, in the current protocol, every client (validator or proposer) is still required to store the entire state locally, with state proofs derived from it, relying on computing cryptographic hashes and comparing them to the expected tree root. + +In a stateless design, all the required information and proofs would instead be included within the block. + +---- + +First, let’s define how we look at **processing a block in a blockchain**. + +We can think of it as a **state transition function**, where: +1. We get some previous state +2. Then we process a block +3. Then we get some new state + +- Original state transition function: ```stf(state, block) -> new_state``` +- Stateless state transition function: ```stf'(state_root, block, witness) -> new_state_root``` + + > - witness = the portions of the state that are read and modified, along with the proofs + > - Instead of the client holding a state, the client holds the state root + +=> If we can efficiently prove the Ethereum state, we unlock entirely new possibilities for **scaling** and **decentralization**. + +--- + +### Current pain points in client development +- **I/O** - writing data to disk (main problem) +- **Sync** - joining the network can take a day in the best case + - re-executing everything from genesis can take 2–3 weeks +- **Block production** + + + +#### Benefits of a stateless design: +- Reduced validator hardware requirements: IO, disk space, and computation +- Faster sync times (near-zero sync time), since a node does not need more than an EL block to join the network +- Clients can choose which parts of the state to store and compete with RPC providers by serving that data +- More people can become validators -> stronger decentralization +- The gas limit can be increased +- Easy [**state expiry**](/docs/wiki/research/stateless/stateless.md#state-expiry) +- Clients can validate blocks out of order + +#### With stateless design: +- It becomes easier to build and implement new EL clients +- We got zk-friendly L1 where we remove heavy use of non-zk-friendly hashes (i.e: [keccak256](/docs/wiki/Cryptography/keccak256.md)) + +> But before statelessness, other roadmap items need to be completed first, such as [Verkle Trees](https://ethereum.org/roadmap/verkle-trees/) and [Proposer-builder separation](https://ethereum.org/roadmap/pbs/). + +## State expiry + +While statelessness removes the need for clients to store the full state, it does not address unbounded state growth on its own. + +However, with a stateless design, it becomes feasible to safely expire or deactivate unused state without harming network participants. + +When to expire: +1. **Expire by rent** + - Direct rent + - Rent via time-to-live (TTL) +2. **Expire by time** + - Refresh by touching + - Everything expires at regular intervals ([ReGenesis proposal](https://hackmd.io/@vbuterin/state_size_management?stext=8196%3A18%3A0%3A1768226177%3AVh_fUA)) + + >**Refresh by touching** is beneficial because: + >- it avoids requiring applications to add complex economic mechanisms to pass state rent costs on to their users; + >- it ensures a clear hard bound on the active state size at all times: (`block_gas_limit / cost_to_touch_state_object * time_to_live_period`). + + >**ReGenesis:** Having large amounts of state expire at regular discrete intervals (ie. ReGenesis) also has these benefits, and it has interesting tradeoffs + >- **key benefit** - easier expiry - no need to walk through the tree and expire things one by one + >- **key downside** - more variability in how much witness data needs to be provided depending on how far into an epoch you are + +### State expiry challenge + +The challenge with state expiry arises when RPC providers need to store both **expired** and **unexpired** state. + +### Alternative approach +An **alternative approach** would be to distribute the data across the validator network using different strategies, thereby **decentralizing state storage** in a **market-driven** way, while still **preserving data availability** for the entire network. + +Each validator could be incentivized to act as an RPC provider for the subset of the state it chooses to store. +The validity of this data would be guaranteed by proofs provided alongside it. +> Such a design would require a global load balancer capable of routing requests for specific parts of the state to the clients that store them. + +---- + +# Levels of statelessness + +Statelessness can be implemented at different levels. + +These models differ in their trade-offs between implementation complexity, resource requirements, and decentralization guarantees. + +In practice, this leads to two main approaches: **(1) weak statelessness** and **(2) strong statelessness**. + +## (1) Weak statelessness +Only block producers need access to the full(or required) state. +Other nodes can verify blocks without storing a local state database. + +In this model: +- proposing a block is expensive +- verifying a block is cheap + +=> This implies that fewer operators may choose to run block-proposing nodes. + +But **decentralization** of **block proposers** is **not critical** as long as as many participants as possible can independently **verify** that the blocks they propose are valid. +> For more details: [Why is it ok to have expensive proposers](https://notes.ethereum.org/WUUUXBKWQXORxpFMlLWy-w#So-why-is-it-ok-to-have-expensive-proposers) + + +>Even with state-storing nodes having higher hardware requirements and being able to store the full state, at some point they will still face the problem of the state size outgrowing even their hardware capacity. +>Because of this, either the previously mentioned [**state expiry**](/docs/wiki/research/stateless/stateless.md#state-expiry) or the concept of **sharding** should be implemented. +> +>
+>Sharding +>Sharding is another scaling technique that addresses the state growth issue by dividing the state into multiple shards, so that no validator ever needs to store the full state. It turns out that if we combine stateless validation with sharding, we can design a highly scalable blockchain that is also very decentralized. +>
+ + +#### MEV considerations + +At first look, this model may seem problematic, as it appears to increase the advantage and profitability of large, well-resourced operators and companies, especially in the context of [MEV](https://chain.link/education-hub/maximal-extractable-value-mev) extraction. + +However, this can be handled by Encrypted mempools ([intro video](https://www.youtube.com/watch?v=mUoWwRoHrvk)) - which prevent builders and proposers from knowing the contents of transactions until after the block is broadcast. + +Additionally, once [Proposer-Builder Separation (PBS)](https://ethereum.org/roadmap/pbs/#pbs-and-mev) is implemented, the block builders might have done sophisticated MEV extraction, but the reward for it goes to the block proposer. +Since the proposer is randomly selected from the entire validator set for each slot, even if a small pool of specialized builders dominates MEV extraction, the reward for it could go to **any validator** on the network, including individual home stakers. + +#### Summary + +In weak statelessness: +- block proposers use full state data to construct witnesses +- a witness is the minimal set of state data and proofs required to validate the state changes in a block +- other validators do not store the full state - they only store the state root (a hash of the entire state) + +Validators receive a block together with its witness and use them to update their state root. +This makes validating nodes extremely lightweight. + +Weak statelessness is expected to be **sufficient for Ethereum’s scaling needs**. + +--- +## (2) Strong statelessness + +In strong statelessness, no nodes have access to the full state data. + +This would enable extremely lightweight nodes, but comes with trade-offs, including making interactions with smart contracts more difficult. + +Strong statelessness is **not currently expected** to be part of Ethereum’s roadmap. + +--- + +# Merkelization and hash functions +The choice of hash function matters for performance in two ways: + +- **Out of circuit** - How fast it is to calculate the hash function result on a regular CPU. +- **In circuit** - How fast this can be calculated within a SNARK circuit under a particular proving system. + +The current [Merkle Patricia Trie (MPT)](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) uses Keccak, which is fast **out-of-circuit** but inefficient in **in-circuit**. + +MPT has an arity of **16** which reduces tree depth and disk lookups, but results in significantly **larger state proofs** - so the **witness** that needs to be transferred between peers is **too large** to safely broadcast within a 12 second slot. +> This is because the witness is a path connecting the data, which is held in leaves, to the root hash. To verify the data it is necessary to have not only all the intermediate hashes that connect each leaf to the root, but also all the "sibling" nodes. Each node in the proof has a sibling that it is hashed with to create the next hash up the trie. This is a lot of data. + +### Proposed tree strategies + +To solve such a thing, we would have to introduce a new tree design - like [Verkle Trees](https://stateless.fyi/trees/vkt-tree.html) and [Binary Tree](https://stateless.fyi/trees/binary-tree.html) proposals, both of which solve disadvantages of the current MPT. +Both of them provide to us: +- A more efficient encoding of data inside the tree. +- Including the account’s code inside the tree, allowing size-efficient partial code proving. +- A more convenient merkelization strategy to generate and verify proofs more efficiently. + +for first 2 points Verkle and Binary tree shares the same [strategy](https://stateless.fyi/trees/data-encoding.html). + +> Verkle trees reduce the witness size by shortening the distance between the leaves of the tree and its root and also eliminating the need to provide sibling nodes for verifying the root hash. Even more space efficiency will be gained by using a powerful **[polynomial commitment](/docs/wiki/research/stateless/stateless.md#polynomial-commitments-simplified)** scheme instead of the hash-style vector commitment. The polynomial commitment allows the **witness** to have a **fixed size** regardless of the number of leaves that it proves. + +>In a stateless design, trees are structured to work in both ZK and non-ZK environments, allowing for flexible switching between hash functions. +> As ZK proofs become more widely adopted and trusted, it is expected that the system can transition to them without requiring major protocol upgrades. + +## Polynomial commitments (simplified) +Polynomial commitments are a special kind of "**hash**" of a polynomial (where that hash has extra properties). + +One of the main extra properties is that: +- If the prover has polynomial `P`, and a coordinate `z` + - he can produce an [**opening**](/docs/wiki/Cryptography/KZG.md#opening-of-the-polynomial) proof `Q` that allows a verifier to check that `P(z) = a`. + +This lets us represent data as a polynomial and prove values. + +### Two main families of polynomial commitments +1. **Pairing-based** commitments (e.g. [KZG](/docs/wiki/Cryptography/KZG.md#kzg-polynomial-commitment-scheme), also known as Kate commitments) + - Verification is done using pairings - eg. [elliptic curve pairing](https://medium.com/@VitalikButerin/exploring-elliptic-curve-pairings-c73c1864e627). + +2. **FRI** commitments + - Is hash-based polynomial commitment scheme (**post quantum secure** and **potentially faster to prove**) + - Uses recursive folding of the polynomial (even/odd decomposition). + +### **Multi openings** + +Key staff with polynomial commitments is that they are especially useful for multi-openings, i.e., proving multiple values of a polynomial at once + +Instead of proving `P(z1) = a1, P(z2) = a2, ...`, separately, we can subtract a polynomial (e.g. [Lagrange polynomial](https://en.wikipedia.org/wiki/Lagrange_polynomial)) that interpolates all desired points. + +This produces one proof (witness) that can verify all points at once. + +This is very valuable for stateless clients, because it allows them to verify a large number of values efficiently with minimal data. + +> You can hear more about polynomial commitments from Justin Drake in these videos: [video 1](https://www.youtube.com/watch?v=bz16BURH_u8&list=PLCGgAwcxXAWwr4l-v_v48wrSJusYGwYLk), [video 2](https://www.youtube.com/watch?v=BfV7HBHXfC0&list=PLCGgAwcxXAWwr4l-v_v48wrSJusYGwYLk&index=3), [video 3](https://www.youtube.com/watch?v=TbNauD5wgXM&list=PLCGgAwcxXAWwr4l-v_v48wrSJusYGwYLk&index=4) + +---- + +# Current challenges +- All required EIPs for statelessness must be implemented before the transition. +- Block verification must be fast(so proofs should not be large). +- State availability in wallets is still a question - a solution like the [Portal Network](https://ethportal.net/overview) could be useful. +- In the current MPT, every value can be accessed via its key, where the key is a hash of the account address or storage slot. Since we are changing the hash function, we need to rehash the entire state, which cannot be done in one slot and could take months to complete. + > the conversion process is described here: [The Verge - Converting the Ethereum state to Verkle trees](https://www.youtube.com/watch?v=F1Ne19Vew6w) + +# Documentation + +- [Ethereum stateless book](https://stateless.fyi/) +- [Statelessness, state expiry and history expiry](https://ethereum.org/roadmap/statelessness/) +- [video: Stateless client witnesses by Vitalik Buterin)](https://www.youtube.com/watch?v=kbcj1TKXaN4) +- [Why is it ok to have expensive proposers](https://notes.ethereum.org/WUUUXBKWQXORxpFMlLWy-w#So-why-is-it-ok-to-have-expensive-proposers) +- [video: Anatomy of a stateless client by Guillaume Ballet](https://www.youtube.com/watch?v=yFJxVSbQNcI) +- [video: The Verge - Converting the Ethereum state to Verkle trees by Guillaume Ballet](https://www.youtube.com/watch?v=F1Ne19Vew6w) +- [VOPS/Partial Stateless nodes by CPerezz](https://cperezz.github.io/presentations/partial-statefulness-ethcc2026.html) +- [A Theory of Ethereum State Size Management by Vitalik Buterin](https://hackmd.io/@vbuterin/state_size_management) +- [The Stateless Client Concept by Vitalik Buterin](https://ethresear.ch/t/the-stateless-client-concept/172) +- [Why it's so important to go stateless by Dankrad Feist](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html#:~:text=,blocks%20requires%20the%20full%20state) +- [Verkle trees by Vitalik Buterin](https://vitalik.eth.limo/general/2021/06/18/verkle.html) +- [presentation by EF Stateless consensus team](https://docs.google.com/presentation/d/1ObHPXLOGqEzCCQvF_aBg2l_RYiX_5wxKIaLZ0zPNScw/edit?slide=id.g2c6554f624f_0_50#slide=id.g2c6554f624f_0_50) +- [What are polynomial commitments?](https://ethresear.ch/t/using-polynomial-commitments-to-replace-state-roots/7095#p-20182-what-are-polynomial-commitments-2) +- [Stateless validation in a sharded blockchain](https://ethresear.ch/t/stateless-validation-in-a-sharded-blockchain/18763) \ No newline at end of file diff --git a/wordlist.txt b/wordlist.txt index 0db7cf2c..59ca6fc5 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -11,17 +11,23 @@ ACD ACL addons Adi +Adi Aditional Adleman +Adleman AES Afser +Afser +Agatevure Agatevure aggregative Akula Aleth Alisie +Alisie allowfullscreen alt +alt amidst amongst Andreas @@ -32,14 +38,17 @@ APIs APS Arbitrum Aritra +arity Arixon ARPANET Arvind +Arvind ary ASE Ashish Asli asm +asm Assche Assertoor assignees @@ -59,8 +68,11 @@ backfill backfilling backfills backticks +backticks +balancer Bankless Banksy +Banksy Barnabe Barnabé Barnabé's @@ -80,6 +92,7 @@ bilinearity BIP bitlist Bitlists +bitmask bitrate bitvector bitvector's @@ -97,6 +110,7 @@ bloXroute bloXroute's BLS bn +bn Bogotá boltdb Boneh @@ -108,6 +122,7 @@ bootup borderless BPE BPO +BPO broadcasted BSON bundlers @@ -123,11 +138,16 @@ CALLCODE calldata canonicalized canonicalness +canonicalness +canonicalness Caplin Carb cartelization Casper Caversaccio +Caversaccio +Caversaccio +CBOR CBOR CDAP cdot @@ -142,6 +162,8 @@ changeset changesets Charmes Chaum +Chaum +checksums checksums Chirag cli @@ -152,10 +174,12 @@ Codasip codebase codebases codebreakers +codebreakers codec CODECOPY codecs coinbase +colapse collateralised collateralized COMIS @@ -171,6 +195,7 @@ Conor Consensys Coq Corbellini +CPerezz CPUs CRS Crypto @@ -182,22 +207,27 @@ cryptoeconomics cryptographic cryptographically cryptology +cryptology +cryptonative cryptonative Cryptopedia cryptopunks cryptosystem cryptosystems +cryptosystems CSP curation customizable cybersecurity Cypherpunk Cypherpunk's +Cypherpunk's Cypherpunks -D'Amato Daemen dafny Dai +Dai +D'Amato Dankrad danksharding Danno @@ -211,10 +241,14 @@ Datagram dataset deboost Decaps +Decaps decrementation decrementing decrypted +decrypted +decrypts decrypts +decrypt DeFi Degatchi DELEGATECALL @@ -238,8 +272,12 @@ devp Devs DEX DHT +DHT +DHT Diffie DigiCash +DigiCash +digram digram DILITHIUM Dimitar @@ -263,6 +301,7 @@ DVT dx EAL eas +eas EB ECADD ECC @@ -270,6 +309,7 @@ ECDH ECDSA ECDSA's ECIES +ECIES ECMUL ECPAIRING ECRECOVER @@ -285,20 +325,23 @@ EIP EIPs eK EL -EL's Elmore +EL's ELs emptyset Encaps +Encaps Encodings Endian enode ENR +ENR env EOA EOAs EOF EOF's +EOF's EOY eP ePBS @@ -308,6 +351,7 @@ Ephemery EPS epubs Erb +Erb ERC ERCs Erigon @@ -315,17 +359,20 @@ Erigon's estimateGas eth etha +etha Ethash ETHCC Ethereum -Ethereum's EthereumJS +EthereumJS +Ethereum's Ethernodes ethers Ethervm ethone ethone's EthPandaOps +EthPandaOps ethresear ethresearch ethrex @@ -333,17 +380,19 @@ ethroadmap ethstaker ETHW EVM -EVM's evmlab EVMONE +EVM's EVMs excalidraw exchangeTransitionConfigurationV Explainer EXTCODESIZE +EXTCODESIZE Extractable extraData fanout +fanout farcaster fastssz faytey @@ -354,15 +403,20 @@ Femboy Ferrin FFG FFT +FFT +filesystem filesystem finalise financials FIPS +FIPS Flashbot's Flashbots Flashboys Flashloans FN +FN +FOCIL FOCIL forall Forkchoice @@ -370,6 +424,7 @@ forkchoiceUpdatedV Forky Formatting FORS +FORS FOSS frac frameborder @@ -385,6 +440,7 @@ Fulu func fungibility Fusaka +Fusaka fuzzer FuzzyVM gasless @@ -394,6 +450,7 @@ gasPrice gasUsed GCM gconnect +gconnect Georgios geq geth @@ -404,6 +461,8 @@ getters ghost Gilles GlaDOS +GlaDOS +Glamsterdam Glamsterdam Goerli Golang @@ -412,15 +471,18 @@ Goomy Goron Gorondan gossipsub +gossipsub Gottfried Gottlob gpg GPL +GPL gradle gradlew Grafana Grandine Grandine's +Grandine's Grigore Grup Guillaume @@ -430,19 +492,24 @@ hackmd Hager halmos hardcoded +hardcoded hardfork HashedStorages Havel +Havel Herc's hevm HMAC +HMAC hoc HOL Holesky homomorphic Hoodi +Hoodi Hopinheimer hotfix +hotfix Hotz Hsiao HSP @@ -469,6 +536,8 @@ infrastracture Infura init initating +initating +InitcodeTransaction InitcodeTransaction initializationCode InsertCoin @@ -478,10 +547,12 @@ intermediation interop interprocess intra +intra invariants IOP IPC IPFS +IPFS Ipsilon IPv IRTF @@ -494,13 +565,20 @@ JUMPDEST JVM JWT kad +kad +kademlia Kademlia Kahn +Kahn +Kanban Kanban Karapetsas Karim +Karim Katex Katya +Katya +KDF KDF KEC keccak @@ -511,6 +589,7 @@ KEVM keystore Kira Kira's +Kira's Kleppmann Koblitz Kubernetes @@ -521,8 +600,10 @@ KZG Lamport Lamport's Lange +Lange lceil LDL +LDL ldots learnings Ledgerwatch @@ -562,29 +643,40 @@ mainnet Mana Manas Manu +Mário mathbb maxEB +maxEB Maximalism Mayowa +Mayowa +Mayowa MDBX MDS meldsun mem Mempool +mempools +Mempools +memtable memtable memtables +memtables Menezes +merkelization merkle -Merkle's Merkleization Merkleize Merkleized Merkleizing +Merkle's +Merkle’s MEV mevboost Michaël middleware Mihai +Mihai minimalistic misconfigure Mitigations @@ -606,19 +698,26 @@ MSIZE mstore MUL multiaddr +multiaddress +Multiaddress Multiaddress +multiaddrs +Multiaddrs Multiaddrs multibase +multibase +Multicast Multicast +multihash Multihash +Multihash +multihashes multihashes multiproofs Murr MVE mvepbs MVI -Mário -n't Nagu Nakamoto Nalepa @@ -632,6 +731,7 @@ neighbours neq Nethermind Nethermind's +Nethermind's neuder newPayloadV NFT @@ -639,12 +739,15 @@ Nim NIST NIST's Nixo +Nixo Noam nonce nonces nonumber NOXX NSS +n't +NTRU NTRU NYU Occhipinti @@ -657,12 +760,16 @@ ommers onboarding onchain OOG +OOG Oorschot opcode +opcode +opcode's opcode's OpenRPC OpenZeppelin oplus +oplus OQS orderflows orgs @@ -675,6 +782,8 @@ Pari Parithosh Pawel PBS +PBS +Pectra Pectra PeerDAS Peeters @@ -684,21 +793,25 @@ performence permissionless permissionlessness PEX +PEX PGA Pigovian Pilipovic pipelining PKCS Plaintext +Plaintext Playdate pmod png POC Pooja +Pooja POS POSIX possibile Postel's +Postel's Potuz Potuz's POV @@ -707,11 +820,11 @@ PQC PQCA PQS PR -PR'ed pre preAccesedStorageKeys prebuilt precompile +precompile precompiled precompiles preconf @@ -725,8 +838,11 @@ preconfirmations preconfirmed preconfirms preconfs +PR'ed +predeploy predeploy Preethi +Preethi preimage Prest prev @@ -735,22 +851,24 @@ privateKey probabilistically programmability proto -proto's protobuf Protolambda +proto's prover Prover's Provers PRs Prysm -Prysm's Prysmatic +Prysm's +Prysm's PSE PSE's pseudorandom pseudorandomly ptc ptsd +ptsd publically pubsub PUSHX @@ -764,9 +882,11 @@ QUIC Quintus Raa Radicle +Radicle radix rahul Rahul's +Rahul's RANDAO Rareskills RB @@ -790,6 +910,7 @@ retesteth Reth Reth's reusability +reusability revm rfloor rightarrow @@ -797,13 +918,16 @@ Rikard RIPEMD Ritchie Rivest +Rivest rK RLMD RLNC RLP RLPx +RLPx roadmap RollCall +RollCall rollup rollup's rollups @@ -816,6 +940,7 @@ runtime Satisfiability Satoshi Satoshi's +Satoshi's scalability scalable schemas @@ -837,7 +962,12 @@ Shacham shadowfork Shafu Shamir +Shamir +Shapella Shapella +sharded +Sharded +Sharded Sharded ShardedKey sharding @@ -845,17 +975,20 @@ ShareAlike Shead Shimon Shisui +Shisui Shor Shor's Siddharth sidechain SigP +SigP Silkwarm Silverman Sipser slashable slashings SLH +SLH SLOAD smlXL SMT @@ -866,11 +999,14 @@ SPHINCS Sproul src SSD +SSD SSF SSLE +SSLE SSTORE SSZ StackTooDeep +StackTooDeep staker stakers Stallman @@ -896,25 +1032,33 @@ subtrees Summa Supermajority surveilling +surveilling +symlinks symlinks Synchronising +Synchronising +sys sys systemd Szabo Takenobu Taleb +Taleb +TalkReq TalkReq Tanenbaum Tani TBD tbhl TCP +TCP Teku testnet testnets Tetris textnormal texttt +texttt timeframe tinygrad TLA @@ -933,9 +1077,11 @@ transactionId trapdoored trie trie's +trie's triggerable trilemma Trin +Trin Trinfilesystem trustless trustlessly @@ -943,6 +1089,7 @@ trustlessness TrustLook TSTORE TTD +TTL Tx txcreate txdatanonzero @@ -959,6 +1106,7 @@ underbrace underflow underflows underpriced +underpriced Unformatted unguessable unhandled @@ -966,6 +1114,7 @@ unincentivized upstreamed utils uTP +uTP UTXO UTXOs UX @@ -976,6 +1125,7 @@ validators Vanstone Varun Vasa +Vasa VB's VDF VDFs @@ -991,6 +1141,7 @@ virtualizing Vitalik Vitalik's VM +VOPS Vyper walkthrough WB @@ -1001,11 +1152,14 @@ Whistleblower Whitepaper WHOAREYOU Winternitz +Winternitz WIP Wireshark +Wireshark withdrawable withdrawalHash wordlist +wordlist WOTS WSL WSS @@ -1022,12 +1176,15 @@ Yoichi Yoni Zanolini Zaryab +Zaryab Zaverucha Zhang Zimmermann +Zimmermann +Zipfian Zipfian zk zkEVMs ZKSNARK ZKSNARKs -Zksync \ No newline at end of file +Zksync