Skip to content
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

sync glossaries between eth.org, ethdocs.org & eth.wiki #5978

Merged
merged 7 commits into from
May 12, 2022
Merged

sync glossaries between eth.org, ethdocs.org & eth.wiki #5978

merged 7 commits into from
May 12, 2022

Conversation

jmcook1186
Copy link
Contributor

Description

This PR collects together entries in the ethdocs.org and eth.wiki glossaries and merges them into the glossary on ethereum.org. There are quite a few new additions. There were also many entries in the glossaries of both ethdocs.org and eth.wiki that I decided NOT to merge into ethereum.org. These are listed below so the PR reviewers can challenge any that they think are actually useful to include (especially those from ethdocs relating to trust and identity - I excluded them as superfluous but think they might actually be quite nice to include).

Entries from ethdocs NOT merged into ethereum.org in this PR:

**deposit**
Digital property placed into a contract involving another party such that if certain conditions are not satisfied that property is automatically forfeited and either credited to a counterparty as insurance against the conditions, or destroyed (= burnt = equally distributed) or donated to some charitable funds. 

**web of trust** 
The idea that if A highly rates B, and B highly rates C, then A is likely to trust C. Complicated and powerful mechanisms for determining the reliability of specific individuals in specific concepts can theoretically be gathered from this principle.

**incentive compatibility**
A protocol is incentive-compatible if everyone is better off “following the rules” than attempting to cheat, at least unless a very large number of people agree to cheat together at the same time (collusion).

**identity** 
A set of cryptographically verifiable interactions that have the property that they were all created by the same person. 

**digital identity** 
The set of cryptographically verifiable transactions signed by the same public key define the digital identity’s behavior. In many real world scenarios (voting) it is desireable that digital identities coincide with real world identities. Ensuring this without violence is an unsolved problem. 

**unique identity** 
A set of cryptographically verifiable interactions that have the property that they were all created by the same person, with the added constraint that one person cannot have multiple unique identities.

**gas price oracle**
A helper function of the Geth client that tries to find an appropriate default gas price when sending transactions.

**serpent** 
Serpent is a high-level language whose syntax is similar to that of Python and it is designed to compile to code for the Ethereum Virtual Machine.

**virtual machine **
In computing, it refers to an emulation of a particular computer system

**NAT** 
Network address translation (NAT) is a methodology of remapping one IP address space into another by modifying network address information in Internet Protocol (IP) datagram packet headers while they are in transit across a traffic routing device.

**homestead** 
Homestead is the second major version release of the Ethereum platform. Homestead includes several protocol changes and a networking change that makes possible further network upgrades: EIP-2 Main homestead hardfork changes; EIP-7 Hardfork EVM update (DELEGATECALL); EIP-8 devp2p forward compatibility. Homestead will launch when block 1,150,000 is reached on the Mainnet. On the Testnet, Homestead will launch at block 494,000. 

**metropolis** 
The third stage of Ethereum’s release. This is the stage when the user interfaces come out (e.g. Mist), including a dapp store, and non-technical users should feel comfortable joining at this point.

**serenity** 
The fourth stage of Ethereum’s release. This is when things are going to get fancy: the network is going to change its mining process from Proof-of-Work to Proof-of-Stake.

**frontier** 
Ethereum was planned to be released in four major steps with Frontier being the name for the first phase. The Frontier release went live on July 30th, 2015. The command line Frontier phase was mainly meant to get mining operations going with the full reward of 5 ether per block and also to promote the emergence of ether exchanges. Frontier surpassed earlier modest expectations and has nurtured tremendous growth of the ecosystem. 

**olympic** 
The Frontier pre-release, which launched on May 9th 2015. It was meant for developers to help test the limits of the Ethereum blockchain. 

**morden** 
Morden is the first Ethereum alternative testnet. It is expected to continue throughout the Frontier and Homestead era.

**consortium chain**
A blockchain where the consensus process is controlled by a pre-selected set of nodes.

**micropayment** 
A micropayment is a financial transaction involving a very small sum of money (<1 USD) and usually one that occurs online.

**crypto-fuel **
Similar to ‘gas’, referring to the amount of cryptocurrency required to power a transaction.

**SPV client** 
A client that downloads only a small part of the blockchain, allowing users of low-power or low-storage hardware like smartphones and laptops to maintain almost the same guarantee of security by sometimes selectively downloading small parts of the state without needing to spend megabytes of bandwidth and gigabytes of storage on full blockchain validation and maintenance. See light client.

**uncle rate** 
The number of uncles produced per block. 

**static node** 
A feature supported by Geth, the Golang Ethereum client, which makes it possible to always connect to specific peers. Static nodes are re-connected on disconnects. For details, see the section on static nodes.

**compiler** 
A program that translates pieces of code written in high level languages into low level executable code.

**network id** 
A number which identifies a particular version of the Ethereum network.

**pending transaction** 
A transaction that is not yet confirmed by the Ethereum network.

**pegging** 
Locking down the exchange rate of the coins/tokens in two chains (usually a main and a side chain) in a certain direction. 

**2-way pegging** 
Locking down the exchange rate of the coins/tokens in two chains (usually a main and a side chain) in both directions.

**checksum** 
A count of the number of bits in a transmission that is included with the unit so that the receiving end can verify that the entirety of the message has been transmitted.

**port** 
A network port is a communication endpoint used by a one of the existing standards of establishing a network conversation (e.g. TCP, UDP).

**IPC** 
Interprocess communication (IPC) is a set of programming interfaces that allow a programmer to coordinate activities among different program processes that can run concurrently in an operating system.

**attach** 
The command used to initiate the Ethereum Javascript console. 

**daemon** 
A computer program that runs as a background process instead of in direct control by an interactive user.
 
**system service** 
See base layer service 

**base layer service** 
Services such as SWARM and Whisper which are built into the Ethereum platform. 

**js** 
Javascript.

**fast sync** 
Instead of processing the entire block-chain one link at a time, and replay all transactions that ever happened in history, fast syncing downloads the transaction receipts along the blocks, and pulls an entire recent state database.

**ICAP format** 
The format of the IBANs defined using the Inter-exchange Client Address Protocol.

**geth** 
Ethereum client implemented in the Golang programming language, based on the protocol as defined in the Ethereum Yellow Paper. 

**eth** 
Ethereum client implemented in the C++ programming language, based on the protocol as defined in the Ethereum Yellow Paper. 

**ethereumjs** 
Ethereum client implemented in the Javascript/Node programming language, based on the protocol as defined in the Ethereum Yellow Paper. 

**pyethereum** 
Ethereum client implemented in the Python programming language, based on the protocol as defined in the Ethereum Yellow Paper. 

**ethereumj **
Ethereum client implemented in the Java programming language, based on the protocol as defined in the Ethereum Yellow Paper. 

**ethereumh **
Ethereum client implemented in the Haskell programming language, based on the protocol as defined in the Ethereum Yellow Paper. 

**parity** 
Ethereum client implemented in the Rust programming language, based on the protocol as defined in the Ethereum Yellow Paper.

**HLL (obsolete) **
Acronym for Higher Level Language, which is what Serpent and Solidity are. HLL is what early Ðapp developers called Ethereum programming languages that did not touch the low level elements. This phrase has been phased out. 

**CLL (obsolete) **
Acronym for C Like Language, which Mutan was. This acronym has been phased out. 

**ES1, ES2, and ES3 (obsolete) **
“Ethereum Script” versions 1,2 and 3. There were early versions of what would become the Ethereum Virtual Machine (EVM). 

**log event **
Contracts are triggered by transactions executed as part of the block verification. If conceived of as a function call, contract execution is asynchronous, and therefore they have no return value. Instead contracts communicate to the outside world with log events. The log events are part of the transaction receipt which is produced when the transaction is executed. The receipts are stored in the receipt trie, the integrity of which is guaranteed by the fact that the current root of the receipt trie is part of the block header alongside the roots of state and state-trie. In a broad sense from the external perspective receipts are part of the Ethereum system state except that they are not readable contracts internally.

Entries from eth.wiki NOT merged into ethereum.org in this PR:

**Stale**: a stale is a block that is created when there is already another block with the same parent out there; stales typically get discarded and are wasted effort.

**Uncle inclusion mechanism**: Ethereum has a mechanism where a block may include its uncles; this ensures that miners that create blocks that do not quite get included into the main chain can still get rewarded.

**Slashing condition**: a condition which, if triggered by a validator, causes the validator’s deposit to be destroyed. 

**Prepare and commit**: two types of messages that validators can send in many types of consensus protocols; see https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c 

**Fault**: an action taken by a validator (or more generally, a participant in a mechanism) that they would not have taken had they correctly followed the protocol 

**Liveness fault**: a validator failing to submit a message that according to the protocol they should have submitted (or submitting a message later than they should have) 

**Censorship fault**: a validator failing to accept valid messages from other validators
Invalidity fault: a validator sending a message that a computer running the correct algorithm could not possibly send, unless its internal state is manipulated with in some way other than rewinding. 
Uniquely attributable fault: a fault such that there exists clear evidence which can be used to determine exactly which validator committed the fault. For example, liveness faults are not uniquely attributable because if a message from A fails to reach B, it could be because A failed to send that message, or because B failed to listen to it, whereas equivocation faults are uniquely attributable.

**Data availability problem and Fisherman’s dilemma**: see https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding 

**Validity**: the property of a state that it is indeed the result of executing a valid history of transactions

**Tight coupling**: chains A and B are tightly coupled if (i) any state of A points to some state of B (and vice versa), and (ii) a state of A should not be considered admissible unless both that state itself and the state of B that it points to are valid and data-available. 

**Loose coupling**: chains A and B are loosely coupled if (i) any state of A points to some state of B (and vice versa), and (ii) they are not tightly coupled.

**Whisper**: an upcoming P2P messaging protocol 

**Swarm**: an upcoming P2P data storage protocol optimized for static web hosting

**Self-executing**: Functioning by itself, not controlled by any other party other than itself. Self-executing smart contracts would cut costs/overhead by removing the need for an arbitrator and trust towards a third party.

Related Issue

#5731
#5690

@gatsby-cloud
Copy link

gatsby-cloud bot commented Apr 8, 2022

Gatsby Cloud Build Report

ethereum-org-website-dev

🎉 Your build was successful! See the Deploy preview here.

Build Details

View the build logs here.

🕐 Build time: 9m

Performance

Lighthouse report

Metric Score
Performance 🔶 24
Accessibility 💚 100
Best Practices 💚 100
SEO 💚 92

🔗 View full report

Copy link
Contributor

@minimalsm minimalsm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall I think this looks good.

I'd like some other input on these to make sure we think they fit into our current listing criteria:

  • This is a term not already found in the glossary (for similar terms, please consider the benefits of a new term vs updating an existing term)
  • This term/definition is not a product advertisement or contain other promotional content
  • This term/definition is directly relevant to Ethereum

One thing we should be careful of is not try to cram every computer science related term into the glossary because Ethereum makes use of it in some way.

src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
Copy link
Member

@wackerow wackerow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmcook1186 Juicy =) Went through all the ones you included in the PR and made comments. I'm cool with starting here, and the other options you left in the PR description can be always be raised as issues and added independently.

Thanks again for your work on this!

src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
Comment on lines +200 to +203
### cryptoeconomics {#cryptoeconomics}

The economics of cryptocurrencies.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine for now but the argument could be made that this is too narrow and should encompass peer-to-peer cryptographic systems generally. Is that what you were thinking @wackerow

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(but happy to ignore this for now for the sake of speed)

src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
Comment on lines 753 to 756
### presale {#presale}

Sale of cryptocurrency before the actual launch of the network.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we note that this was a form of initial ETH issuance that did not come from actual proof-of-work mining or proof-of-stake validating? Okay with just keeping it simple too, just a thought

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we should explain this somewhere on the site, but not here. One (crude) way I've heard it put is glossaries should focus on definitions, not trivia.

src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
src/content/glossary/index.md Outdated Show resolved Hide resolved
jmcook1186 and others added 2 commits May 6, 2022 10:25
Copy link
Contributor

@minimalsm minimalsm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉🎉🎉

@minimalsm minimalsm merged commit 11da2ad into ethereum:dev May 12, 2022
@corwintines corwintines mentioned this pull request May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
content 🖋️ This involves copy additions or edits
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants