|
193 | 193 | "keystore-definition": "Every account’s private key/address pair exists as a single keyfile in an Ethereum client. These are JSON text files which contains the encrypted private key of the account, which can only be decrypted with the password entered during account creation.",
|
194 | 194 | "keccak-256-term": "Keccak-256",
|
195 | 195 | "keccak-256-definition": "Cryptographic <a href=\"/glossary/#hash\">hash</a> function used in Ethereum. Keccak-256 was standardized as <a href=\"/glossary/#sha\">SHA</a>-3.",
|
| 196 | + "layer-1-term": "Layer 1", |
| 197 | + "layer-1-definition": "Layer 1 refers to the main blockchain in a multi-level blockchain network. For example, Ethereum and Bitcoin are layer one blockchains. Many layer two blockchain offload resource-intense transactions to their separate blockchain, while continuing to use Ethereum's or Bitcoin's layer one blockchain for security purposes.", |
196 | 198 | "layer-2-term": "Layer 2",
|
197 | 199 | "layer-2-definition": "An area of development focused on layering improvements on top of the Ethereum protocol. These improvements are related to <a href=\"/glossary/#transaction\">transaction</a> speeds, cheaper <a href=\"/glossary/#transaction-fee\">transaction fees</a>, and transaction privacy. <a href=\"/layer-2/\">More on layer 2</a>.",
|
198 | 200 | "library-term": "Library",
|
199 | 201 | "library-definition": "A special type of <a href=\"/glossary/#smart-contract\">contract</a> that has no payable functions, no fallback function, and no data storage. Therefore, it cannot receive or hold ether, or store data. A library serves as previously deployed code that other contracts can call for read-only computation. <a href=\"/developers/docs/smart-contracts/libraries/\">More on smart contract libraries</a>.",
|
200 | 202 | "light-client-term": "Light client",
|
201 | 203 | "light-client-definition": "An Ethereum client that does not store a local copy of the <a href=\"/glossary/#blockchain\">blockchain</a>, or validate blocks and <a href=\"/glossary/#transaction\">transactions</a>. It offers the functions of a <a href=\"/glossary/#wallet\">wallet</a> and can create and broadcast transactions.",
|
| 204 | + "liquidity-term": "Liquidity", |
| 205 | + "liquidity-definition": "Liquidity is how quickly and easily an asset can be converted into cash or another asset. Decentralized exchanges like Uniswap have multiple liquidity pools where asset holders can deposit their assets where traders can buy and sell them in a decentralized way in exchange for rewards.", |
202 | 206 | "lmd-ghost-term": "LMD-GHOST",
|
203 | 207 | "lmd-ghost-definition": "The <a href=\"/glossary/#fork-choice-algorithm\">fork-choice algorithm</a> used by Ethereum's consensus clients to identify the head of the chain. LMD-GHOST is an acronym standing for \"Latest Message Driven Greediest Heaviest Observed SubTree\" which means that the head of the chain is the block with the greatest accumulation of <a href=\"/glossary/#attestation\">attestations</a> in its history.",
|
204 | 208 | "mainnet-term": "Mainnet",
|
205 | 209 | "mainnet-definition": "Short for \"main network,\" this is the main public Ethereum <a href=\"/glossary/#blockchain\">blockchain</a>.",
|
| 210 | + "max-fee-per-gas-term": "Max Fee Per Gas", |
| 211 | + "max-fee-per-gas-definition": "The Max Fee is the absolute maximum amount a user is willing to pay per unit of gas (<a href=\"/glossary/#gwei\">gwei</a>) to get a transaction included in a block.", |
206 | 212 | "merkle-patricia-tree-term": "Merkle Patricia Tree (MPT)",
|
207 | 213 | "merkle-patricia-tree-definition": "A data structure used in Ethereum to efficiently store key-value pairs.",
|
| 214 | + "merkle-root-term": "Merkle Root", |
| 215 | + "merkle-root-definition": "A Merkle root is the single top hash of a Merkle tree. It verifies all transactions within a block.", |
208 | 216 | "message-term": "Message",
|
209 | 217 | "message-definition": "An <a href=\"/glossary/#internal-transaction\">internal transaction</a> that is never serialized and only sent within the <a href=\"/glossary/#evm\">EVM</evm>.",
|
210 | 218 | "message-call-term": "Message call",
|
|
225 | 233 | "node-definition": "A software client that participates in the network. <a href=\"/developers/docs/nodes-and-clients/\">More on nodes and clients</a>.",
|
226 | 234 | "nonce-term": "Nonce",
|
227 | 235 | "nonce-definition": "In cryptography, a value that can only be used once. An account nonce is a transaction counter in each account, which is used to prevent replay attacks.",
|
| 236 | + "off-chain-term": "Off-Chain", |
| 237 | + "off-chain-definition": "Off-chain means any transaction or data that exists outside the blockchain. Because committing every transaction on-chain can be expensive and inefficient, third-party tools like oracles that handle pricing data, or layer 2 solutions that execute a higher throughput of transactions, handle a bulk of the processing work off-chain, and will submit information on-chain at less frequent intervals.", |
228 | 238 | "ommer-term": "Ommer (uncle) block",
|
229 | 239 | "ommer-definition": "When a proof-of-work <a href=\"/glossary/#miner\">miner</a> finds a valid <a href=\"/glossary/#block\">block</a>, another miner may have published a competing block which is added to the tip of the blockchain first. This valid, but stale, block can be included by newer blocks as <em>ommers</em> and receive a partial block reward. The term \"ommer\" is the preferred gender-neutral term for the sibling of a parent block, but this is also sometimes referred to as an \"uncle\". This was relevant for Ethereum when it was a <a href=\"/glossary/#pow\">proof-of-work</a> network, but ommers are not a feature of <a href=\"/glossary/#pos\">proof-of-stake</a> Ethereum because precisely one block proposer is selected in each slot.",
|
| 240 | + "on-chain-term": "On-Chain", |
| 241 | + "on-chain-definition": "Refers to actions or transactions that happen on the blockchain and are publicly available.<br /><br />Think of it as writing something in a big, shared notebook that everyone can see and check, making sure that whatever is written (like sending digital money or making a contract) is permanent and can't be changed or erased.", |
230 | 242 | "optimistic-rollup-term": "Optimistic rollup",
|
231 | 243 | "optimistic-rollup-definition": "A <a href=\"/glossary/#rollups\">rollup</a> of transactions that use <a href=\"/glossary/#fraud-proof\">fraud proofs</a> to offer increased <a href=\"/glossary/#layer-2\">layer 2</a> transaction throughput while using the security provided by <a href=\"/glossary/#mainnet\">Mainnet</a> (layer 1). Unlike <a href=\"/glossary/#plasma\">Plasma</a>, a similar layer 2 solution, Optimistic rollups can handle more complex transaction types – anything possible in the <a href=\"/glossary/#evm\">EVM</a>. They do have latency issues compared to <a href=\"/glossary/#zk-rollups\">Zero-knowledge rollups</a> because a transaction can be challenged via the fraud proof. <a href=\"/developers/docs/scaling/optimistic-rollups/\">More on Optimistic rollups</a>.",
|
232 | 244 | "oracle-term": "Oracle",
|
|
0 commit comments