From e67fc4fbf3b2cbe85b9c612f555fee2dcf33ea4a Mon Sep 17 00:00:00 2001 From: anweshknayak Date: Wed, 27 Oct 2021 02:21:09 +0530 Subject: [PATCH] FIX: broken links to various markdown pages --- ...dapp-browsers-wallets-and-other-projects.md | 6 +++--- ...ereum-virtual-machine-(evm)-awesome-list.md | 2 +- concepts/evm/evm.md | 6 +++--- concepts/light-client-protocol.md | 2 +- concepts/security-categorization.md | 4 ++-- faqs/faqs.md | 6 +++--- faqs/glossary.md | 4 ++-- fundamentals/dapp-developer-resources.md | 2 +- fundamentals/dapp-development.md | 16 +++++++++------- fundamentals/design-rationale.md | 6 +++--- fundamentals/ethereum-introduction.md | 14 +++++++------- fundamentals/fundamentals.md | 18 +++++++++--------- fundamentals/getting-started.md | 2 +- fundamentals/mining.md | 8 ++++---- governance/maintainers.md | 2 +- governance/polices-and-guidelines.md | 4 ++-- howto/ethereum-development-tutorial.md | 2 +- ...ness-economics-and-other-research-topics.md | 2 +- roadmap/releases.md | 8 ++++---- scalability/chain-fibers-redux.md | 2 +- sharding/Sharding-FAQs.md | 8 ++++---- 21 files changed, 63 insertions(+), 61 deletions(-) diff --git a/clients/clients-tools-dapp-browsers-wallets-and-other-projects.md b/clients/clients-tools-dapp-browsers-wallets-and-other-projects.md index 9d38d47..51985bf 100644 --- a/clients/clients-tools-dapp-browsers-wallets-and-other-projects.md +++ b/clients/clients-tools-dapp-browsers-wallets-and-other-projects.md @@ -49,9 +49,9 @@ NOTE: all clients are listed in alphabetical order. ## Other projects, tools, etc. -- [sharding](./sharding-introduction-r-d-compendium.md) -- [Casper Proof-of-Stake](./casper-proof-of-stake-compendium.md) -- [smart contract languages](./dapp-development.md): +- [sharding](../sharding/sharding-introduction-r-d-compendium.md) +- [Casper Proof-of-Stake](../concepts/casper-proof-of-stake-compendium.md) +- [smart contract languages](../fundamentals/dapp-development.md): - Solidity: [repo](https://github.com/ethereum/solidity), join the chat at , [docs](https://solidity.readthedocs.org/en/latest/), see the above link for more resources. - Vyper: [repo](https://github.com/ethereum/vyper) - LLL and other deprecated languages diff --git a/concepts/evm/ethereum-virtual-machine-(evm)-awesome-list.md b/concepts/evm/ethereum-virtual-machine-(evm)-awesome-list.md index f6dcdf2..0baa270 100644 --- a/concepts/evm/ethereum-virtual-machine-(evm)-awesome-list.md +++ b/concepts/evm/ethereum-virtual-machine-(evm)-awesome-list.md @@ -12,7 +12,7 @@ A curated list of resources on the Ethereum Virtual Machine (EVM), which is the Not listed there yet, but in the spirit of [![Awesome](https://cdn.rawgit.com/sindresorhus/awesome/d7305f38d29fed78fa85652e3a63e154dd8e8829/media/badge.svg)](https://github.com/sindresorhus/awesome) -Here is [how to contribute](./contributing.md). +Here is [how to contribute](../../governance/contributing.md). ## Specification diff --git a/concepts/evm/evm.md b/concepts/evm/evm.md index 67ec59e..bdc022a 100644 --- a/concepts/evm/evm.md +++ b/concepts/evm/evm.md @@ -14,7 +14,7 @@ A curated list of resources on the Ethereum Virtual Machine (EVM), which is the Not listed there yet, but in the spirit of [![Awesome](https://cdn.rawgit.com/sindresorhus/awesome/d7305f38d29fed78fa85652e3a63e154dd8e8829/media/badge.svg)](https://github.com/sindresorhus/awesome) -Here is [how to contribute](./contributing.md). +Here is [how to contribute](../../governance/contributing.md). ## Specification @@ -38,7 +38,7 @@ Here is [how to contribute](./contributing.md). - A hands on guide to understanding how the EVM works, with examples written in raw byte-code and solidity * [Diving Into The Ethereum Virtual Machine](https://medium.com/@hayeah/diving-into-the-ethereum-vm-6e8d5d2f3c30) - An article series examining different aspects of the EVM by walking you through Solidity's assembly output -* [Consensus Datastructures](./consensus-datastructures.md) +* [Consensus Datastructures](../../fundamentals/specs/consensus-datastructures.md) ## Tests @@ -61,7 +61,7 @@ Here is [how to contribute](./contributing.md). - A Python implementation designed to be highly configurable and modular and compliant with the Ethereum test suite, work is in progress on it to run a full node and develop sharding. * [EthereumJ](https://github.com/ethereum/ethereumj) in Java - A client with its own EVM implementation -* For more, see [here](./clients-tools-dapp-browsers-wallets-and-other-projects.md). +* For more, see [here](../../clients/clients-tools-dapp-browsers-wallets-and-other-projects.md). ### Other Implementations diff --git a/concepts/light-client-protocol.md b/concepts/light-client-protocol.md index 187feaa..7f5f319 100644 --- a/concepts/light-client-protocol.md +++ b/concepts/light-client-protocol.md @@ -9,7 +9,7 @@ The purpose of the light client protocol is to allow users in low-capacity envir ## Background: Patricia Merkle Trees -All substantial quantities of data in Ethereum are stored in a data structure known as the [Patricia Merkle tree](./fundamentals/patricia-tree.md), a tree structure where each node in the tree is the hash of its children. Each set of key/value pairs maps to a unique root hash, and only a small subset of nodes is needed to prove that a particular key/value combination is in the tree corresponding to a particular root hash. +All substantial quantities of data in Ethereum are stored in a data structure known as the [Patricia Merkle tree](../fundamentals/patricia-tree.md), a tree structure where each node in the tree is the hash of its children. Each set of key/value pairs maps to a unique root hash, and only a small subset of nodes is needed to prove that a particular key/value combination is in the tree corresponding to a particular root hash. The size complexity of a Merkle proof scales linearly with the height of a tree; because each child in a tree has a particular number of children (in our case, up to 17), this means that the size complexity of a Merkle proof is logarithmic in the quantity of data stored. This means that, even if the entire state tree is a few gigabytes in size, if a node receives a state root from a trusted source that node has the ability to know with full certainty the validity of any information with the tree by only downloading a few kilobytes of data in a proof. diff --git a/concepts/security-categorization.md b/concepts/security-categorization.md index 0aeae95..7b57e3c 100755 --- a/concepts/security-categorization.md +++ b/concepts/security-categorization.md @@ -1,6 +1,6 @@ # Security Categorization -[See also](./design-rationale.md), for descriptions of potentially counterintuitive design decisions in Ethereum. +[See also](../fundamentals/design-rationale.md), for descriptions of potentially counterintuitive design decisions in Ethereum. The purpose of this document is to attempt to create a taxonomy of key security properties that we are targeting for the Ethereum protocol, implementation and materials to have at launch time, as well as provide supplementary information where needed for each one. @@ -13,7 +13,7 @@ The purpose of this document is to attempt to create a taxonomy of key security ## Proof of Work -The working spec description of Dagger Hashimoto is available [here](./ethash.md). +The working spec description of Dagger Hashimoto is available [here](./ethash/ethash.md). The algorithm is intended to have the following key properties: diff --git a/faqs/faqs.md b/faqs/faqs.md index ca2463e..901c5ed 100644 --- a/faqs/faqs.md +++ b/faqs/faqs.md @@ -17,7 +17,7 @@ If you prefer to learn by watching videos, see: ## How do I buy Ether or ETH? -Read [this](./fundamentals/ethereum-introduction.md#how-do-you-buy-and-sell-ether-the-currency-of-ethereum). +Read [this](../fundamentals/ethereum-introduction.md#how-do-you-buy-and-sell-ether-the-currency-of-ethereum). ## Where can I learn more about Ethereum? @@ -120,7 +120,7 @@ With the eth client ### Where can I learn about contract development? - Articles - - [Ethereum Development Tutorial](./howto/ethereum-development-tutorial.md) + - [Ethereum Development Tutorial](../howto/ethereum-development-tutorial.md) - Videos - [Ethereum](https://www.youtube.com/user/ethereumproject/videos) - [EtherCasts](https://www.youtube.com/user/EtherCasts/videos) @@ -177,7 +177,7 @@ With the eth client - [The PoC 6 API for C++](https://github.com/ethereum/cpp-ethereum/wiki/Client-Development-with-PoC-6) - [The PoC 5 API for Go](https://github.com/ethereum/go-ethereum/wiki/PoC-5-Public-Go-API) - [The PoC 6 API for QML](https://github.com/ethereum/go-ethereum/wiki/QML-PoC6-API) -- [The PoC 7 API for JavaScript](./javascript-api.md) +- [The PoC 7 API for JavaScript](https://github.com/ethereum/wiki/wiki/JavaScript-API) ### Where can I learn about ÐApp development? diff --git a/faqs/glossary.md b/faqs/glossary.md index d7932f1..cd7c971 100644 --- a/faqs/glossary.md +++ b/faqs/glossary.md @@ -34,7 +34,7 @@ See also: See also: -- **Serialization**: the process of converting a data structure into a sequence of bytes. Ethereum internally uses an encoding format called recursive-length prefix encoding (RLP), described [here](./fundamentals/rlp.md) +- **Serialization**: the process of converting a data structure into a sequence of bytes. Ethereum internally uses an encoding format called recursive-length prefix encoding (RLP), described [here](../fundamentals/rlp.md) - **Patricia tree** (or **trie**): a data structure which stores the state of every account. The trie is built by starting from each individual node, then splitting the nodes into groups of up to 16 and hashing each group, then making hashes of hashes and so forth until there is one final "root hash" for the entire trie. The trie has the important properties that (1) there is exactly one possible trie and therefore one possible root hash for each set of data, (2) it is very easy to update, add or remove nodes in the trie and generate the new root hash, (3) there is no way to modify any part of the tree without changing the root hash, so if the root hash is included in a signed document or a valid block the signature or proof of work secures the entire tree, and (4) one can provide just the "branch" of a tree going down to a particular node as cryptographic proof that that node is indeed in the tree with that exact content. Patricia trees are also used to store the internal storage of accounts as well as transactions and ommers. See [here](http://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) for a more detailed description. - **Uncle**: See **Ommer**, the gender-neutral alternative to aunt/uncle. - **Ommer**: a child of a parent of a parent of a block that is not the parent, or more generally a child of an ancestor that is not itself an ancestor. If A is an ommer of B, B is a **nibling** (niece/nephew) of A. @@ -50,7 +50,7 @@ See also: ## Casper and scaling research -See [proof of stake FAQs](./proof-of-stake-faqs.md) and [sharding FAQs](./sharding-faqs.md). +See [proof of stake FAQs](../concepts/proof-of-stake-faqs.md) and [sharding FAQs](../sharding/sharding-faqs.md). - **Security deposit**: a quantity of ether that a user deposits into a mechanism (often a proof of stake consensus mechanism, though this can also be used for other applications) that a user normally expects to be able to eventually withdraw and recover, but which can be taken away in the event of malfeasance from the user's side. - **Validator**: a participant in proof of stake consensus. Validators need to submit a security deposit in order to get included in the validator set. diff --git a/fundamentals/dapp-developer-resources.md b/fundamentals/dapp-developer-resources.md index 8e5c68a..0655777 100644 --- a/fundamentals/dapp-developer-resources.md +++ b/fundamentals/dapp-developer-resources.md @@ -5,7 +5,7 @@ As a Ðapp developer you have three main resources which allow Ðapp development ## Main Resources - [Web3 JavaScript API](JavaScript-API) - This is the main JavaScript SDK to use when you want to interact with a nodes API -- [JSON RPC API](JSON-RPC) - This is the low level JSON RPC 2.0 interface to interface with a node. This API is used by the [Web3 JavaScript API](./javascript-api.md). +- [JSON RPC API](JSON-RPC) - This is the low level JSON RPC 2.0 interface to interface with a node. This API is used by the [Web3 JavaScript API](https://web3js.readthedocs.io/en/v1.2.9/index.html). - [Solidity Documentation](https://solidity.readthedocs.org/en/latest/) - Solidity is the Ethereum-developed Smart Contract language, which compiles to EVM (Ethereum Virtual Machine) opcodes. - [Remix IDE](http://remix.ethereum.org/) - Solidity editor in the browser that helps efficient writing, debugging and deploying contracts - [Dapp Insight](https://dappinsight.com) - This is a most popular Dapp analytics tool which listing all the running Dapps in the world with their true usage data. diff --git a/fundamentals/dapp-development.md b/fundamentals/dapp-development.md index b2c8e55..ba9f734 100644 --- a/fundamentals/dapp-development.md +++ b/fundamentals/dapp-development.md @@ -15,12 +15,14 @@ ## Miscellaneous resources and info -- [Safety](./howto/smart-contract-safety.md) -- [ÐApp Developer Resources](./dapp-developer-resources.md) -- [JavaScript API](./javascript-api.md) -- [JSON RPC API](./json-rpc.md) +- [Safety](../howto/smart-contract-safety.md) +- [ÐApp Developer Resources](../fundamentals/dapp-developer-resources.md) +- [JavaScript API](https://web3js.readthedocs.io/en/v1.2.9/index.html) +- [JSON RPC API](../json-rpc/api.md) - [Useful Ðapp Patterns](https://github.com/ethereum/wiki/wiki/Useful-Ðapp-Patterns) -- [Standardized Contract APIs](./standardized_contract_apis.md) -- [Ethereum development tutorial](./howto/ethereum-development-tutorial.md) -- [ÐApp using Meteor](./howto/dapp-using-meteor.md) +- [Standardized Contract APIs](../concepts/standardized-contract-apis.md) +- [Ethereum development tutorial](../howto/ethereum-development-tutorial.md) +- [ÐApp using Meteor](../howto/dapp-using-meteor.md) - [Dapp Insight: dapp statistics](https://dappinsight.com) + + diff --git a/fundamentals/design-rationale.md b/fundamentals/design-rationale.md index 41a8a82..6d21d38 100644 --- a/fundamentals/design-rationale.md +++ b/fundamentals/design-rationale.md @@ -58,7 +58,7 @@ The Merkle Patricia tree/trie, previously envisioned by Alan Reiner and implemen 1. Every unique set of key/value pairs maps uniquely to a root hash, and it is not possible to spoof membership of a key/value pair in a trie (unless an attacker has ~2^128 computing power) 2. It is possible to change, add or delete key/value pairs in logarithmic time -This gives us a way of providing an efficient, easily updateable, "fingerprint" of our entire state tree. The Ethereum MPT is formally described [here](./fundamentals/patricia-tree.md). +This gives us a way of providing an efficient, easily updateable, "fingerprint" of our entire state tree. The Ethereum MPT is formally described [here](./patricia-tree.md). Specific design decisions in the MPT include: @@ -70,7 +70,7 @@ Specific design decisions in the MPT include: ## RLP -RLP ("recursive length prefix") encoding is the main serialization format used in Ethereum, and is used everywhere - for blocks, transactions, account state data and wire protocol messages. RLP is formally described [here](./fundamentals/rlp.md). +RLP ("recursive length prefix") encoding is the main serialization format used in Ethereum, and is used everywhere - for blocks, transactions, account state data and wire protocol messages. RLP is formally described [here](./rlp.md). RLP is intended to be a highly minimalistic serialization format; its sole purpose is to store nested arrays of bytes. Unlike [protobuf](https://developers.google.com/protocol-buffers/docs/pythontutorial), [BSON](http://bsonspec.org/) and other existing solutions, RLP does not attempt to define any specific data types such as booleans, floats, doubles or even integers; instead, it simply exists to store structure, in the form of nested arrays, and leaves it up to the protocol to determine the meaning of the arrays. Key/value maps are also not explicitly supported; the semi-official suggestion for supporting key/value maps is to represent such maps as `[[k1, v1], [k2, v2], ...]` where `k1, k2...` are sorted using the standard ordering for strings. @@ -106,7 +106,7 @@ Where: - `logs` is a list of items of the form `[address, [topic1, topic2...], data]` that are produced by the `LOG0` ... `LOG4` opcodes during the execution of the transaction (including by the main call and sub-calls). `address` is the address of the contract that produced the log, the topics are up to 4 32-byte values, and the data is an arbitrarily sized byte array. - `logbloom` is a bloom filter made up of the addresses and topics of all logs in the transaction. -There is also a bloom in the block header, which is the OR of all of the blooms for the transactions in the block. The purpose of this construction is to make the Ethereum protocol light-client friendly in as many ways as possible. For more details on Ethereum light clients and their use cases, see the [light client page (principles section)](light-client-protocol.md#principles). +There is also a bloom in the block header, which is the OR of all of the blooms for the transactions in the block. The purpose of this construction is to make the Ethereum protocol light-client friendly in as many ways as possible. For more details on Ethereum light clients and their use cases, see the [light client page (principles section)](../concepts/light-client-protocol.md#principles). ## Uncle incentivization diff --git a/fundamentals/ethereum-introduction.md b/fundamentals/ethereum-introduction.md index db91abc..905fdb3 100755 --- a/fundamentals/ethereum-introduction.md +++ b/fundamentals/ethereum-introduction.md @@ -14,7 +14,7 @@ For an introduction to blockchains, see [this TED talk](https://www.youtube.com/ Ethereum has been described in several ways. -The simplest way to understand Ethereum is to know what it does. Just like how it is not necessary to fully understand the intricate workings of how a car works in order to appreciate it's utility, or to understand how electricity arrives in your light bulb when you turn it on, understanding the current and potential utility of Ethereum is a good start. Ethereum can be used for virtually any kind of transaction or agreement (to put it another way, any kind of activity that has an economic or governance aspect), at a lower cost than conventional alternatives, such as debit card payments, in a way that is trustless, secure, safe and censorship-resistant, all with high probability. An extensive and growing list of uses is available [here](../decentralized-apps-dapps.md). +The simplest way to understand Ethereum is to know what it does. Just like how it is not necessary to fully understand the intricate workings of how a car works in order to appreciate it's utility, or to understand how electricity arrives in your light bulb when you turn it on, understanding the current and potential utility of Ethereum is a good start. Ethereum can be used for virtually any kind of transaction or agreement (to put it another way, any kind of activity that has an economic or governance aspect), at a lower cost than conventional alternatives, such as debit card payments, in a way that is trustless, secure, safe and censorship-resistant, all with high probability. An extensive and growing list of uses is available [here](../fundamentals/decentralized-apps-dapps.md). @@ -54,7 +54,7 @@ The platform part of Ethereum makes it much more useful than just a cryptocurren ### List of dapps -For a list of dapps, visit [here](../decentralized-apps-dapps.md). +For a list of dapps, visit [here](../fundamentals/decentralized-apps-dapps.md). ## Market analysis @@ -62,7 +62,7 @@ Assessing the actual usage of blockchains is a more reliable indicator than the -As of the 9th of January 2018, [the market capitalisation of Ethereum is $118.5 billion USD](https://cryptolization.com/ethereum) (refer to the link for the latest figure), and [it has been in circulation since 30 July 2015](./../releases.md), with the [first transaction](https://www.reddit.com/r/ethereum/comments/6qildp/what_is_the_first_ever_ethereum_transaction/) after the [genesis block](https://etherscan.io/block/0) using Ethereum on [7 August 2015](https://etherscan.io/block/46147). Compare this with the next largest and the current largest cryptocurrency, [Bitcoin, with a market cap of $253.0 billion USD](https://cryptolization.com/ethereum), where [it has been in circulation since January 2009](http://www.newyorker.com/reporting/2011/10/10/111010fa_fact_davis). Technically, Ethereum has had a much faster growth rate, while more importantly for long term investment (I do not encourage speculation or buying with capital that you can't afford to lose, without due diligence as that only causes volatility as has been seen) the fundamentals are much better than Bitcoin. While it is true that Bitcoin has more of a market and currency, e.g. in terms of more entities that will accept it as a form of payment, the creator of this wiki expects that time will change that (indeed the market cap of Ethereum recently surpassed half that of Bitcoin, around May 2017). Also, [the number of transactions of Ethereum surpassed that of several cryptocurrencies combined on 22 Nov 2017](https://www.reddit.com/r/ethereum/comments/7est9k/ethereum_is_now_processing_more_transactions_a/). However, note [this retort](https://www.reddit.com/r/ethereum/comments/7est9k/ethereum_is_now_processing_more_transactions_a/dq7a31u/). +As of the 9th of January 2018, [the market capitalisation of Ethereum is $118.5 billion USD](https://cryptolization.com/ethereum) (refer to the link for the latest figure), and [it has been in circulation since 30 July 2015](../roadmap/releases.md), with the [first transaction](https://www.reddit.com/r/ethereum/comments/6qildp/what_is_the_first_ever_ethereum_transaction/) after the [genesis block](https://etherscan.io/block/0) using Ethereum on [7 August 2015](https://etherscan.io/block/46147). Compare this with the next largest and the current largest cryptocurrency, [Bitcoin, with a market cap of $253.0 billion USD](https://cryptolization.com/ethereum), where [it has been in circulation since January 2009](http://www.newyorker.com/reporting/2011/10/10/111010fa_fact_davis). Technically, Ethereum has had a much faster growth rate, while more importantly for long term investment (I do not encourage speculation or buying with capital that you can't afford to lose, without due diligence as that only causes volatility as has been seen) the fundamentals are much better than Bitcoin. While it is true that Bitcoin has more of a market and currency, e.g. in terms of more entities that will accept it as a form of payment, the creator of this wiki expects that time will change that (indeed the market cap of Ethereum recently surpassed half that of Bitcoin, around May 2017). Also, [the number of transactions of Ethereum surpassed that of several cryptocurrencies combined on 22 Nov 2017](https://www.reddit.com/r/ethereum/comments/7est9k/ethereum_is_now_processing_more_transactions_a/). However, note [this retort](https://www.reddit.com/r/ethereum/comments/7est9k/ethereum_is_now_processing_more_transactions_a/dq7a31u/). ## Issues @@ -107,7 +107,7 @@ For the continual improvement of humanity, there needs to be balance in life bet ## Bugs -Ethereum has had expensive bugs, such as those listed [here](../major-issues-resulting-in-lost-or-stuck-funds.md) and [here](../famous-bugs.md). +Ethereum has had expensive bugs, such as those listed [here](../faqs/major-issues-resulting-in-lost-or-stuck-funds.md) and [here](../faqs/famous-bugs.md). ## How do you buy and sell Ether, the currency of Ethereum? @@ -128,16 +128,16 @@ If you want to help contribute to core development, there is also: ## Core development -- [client development](../clients-tools-dapp-browsers-wallets-and-other-projects.md); +- [client development](../clients/clients-tools-dapp-browsers-wallets-and-other-projects.md); - if you're interested in testing, see the documentation [here](https://ethereum-tests.readthedocs.io/en/latest/), as well as [the Github tests repo](https://github.com/ethereum/tests), [a Gist here (it is outdated)](https://gist.github.com/Souptacular/fd197b1fac7c6d2660b0bef27a33ed40#lll-and-evm-stack-resources), and [Gitter here](https://gitter.im/ethereum/tests); - documentation and specification review, e.g. (and in particular) of [EIPs](https://github.com/ethereum/EIPs); - [many other repositories](https://github.com/ethereum). -For R&D, refer to [here](./../rd.md). +For R&D, refer to [here](../research/rd.md). ## Programming languages -- Learn Python first, e.g. with [Learn Python the Hard Way](https://www.learnpythonthehardway.org/) (I learnt using this, but it's rather condescending, so I'd recommend [Pydocs](https://docs.python.org/3/) instead). There's others, e.g. [Codecademy](https://www.codecademy.com/learn/learn-python), and [Coursera](https://www.coursera.org/courses?languages=en&query=learn+python), etc. Knowing Python is useful for research and demonstration, with demonstration e.g. for [client development](./../clients-tools-dapp-browsers-wallets-and-other-projects.md), e.g. for [Py-EVM](https://github.com/ethereum/py-evm) which is being used as an Ethereum client, to implement statelessness and sharding, as well as [vyper](https://github.com/ethereum/Vyper), an experimental, secure, smart contract programming language; +- Learn Python first, e.g. with [Learn Python the Hard Way](https://www.learnpythonthehardway.org/) (I learnt using this, but it's rather condescending, so I'd recommend [Pydocs](https://docs.python.org/3/) instead). There's others, e.g. [Codecademy](https://www.codecademy.com/learn/learn-python), and [Coursera](https://www.coursera.org/courses?languages=en&query=learn+python), etc. Knowing Python is useful for research and demonstration, with demonstration e.g. for [client development](../clients/clients-tools-dapp-browsers-wallets-and-other-projects.md), e.g. for [Py-EVM](https://github.com/ethereum/py-evm) which is being used as an Ethereum client, to implement statelessness and sharding, as well as [vyper](https://github.com/ethereum/Vyper), an experimental, secure, smart contract programming language; - [LLL](https://media.consensys.net/an-introduction-to-lll-for-ethereum-smart-contract-development-e26e38ea6c23) (also see [here](https://github.com/ethereum/solidity/tree/develop/liblll) and [here](https://github.com/ethereum/solidity/tree/develop/lllc)); - [JULIA](https://solidity.readthedocs.io/en/develop/julia.html), an intermediate language for different Ethereum virtual machines; diff --git a/fundamentals/fundamentals.md b/fundamentals/fundamentals.md index a00fc53..fda7a9c 100644 --- a/fundamentals/fundamentals.md +++ b/fundamentals/fundamentals.md @@ -10,12 +10,12 @@ tags: There are numerous pages underneath me. -* [enode-url-format.md](fundamentals/enode-url-format.md) -* [ethereum-introduction.md](fundamentals/ethereum-introduction.md) -* [getting-ether.md](fundamentals/getting-ether.md) -* [glossary.md](fundamentals/glossary.md) -* [mining.md](fundamentals/mining.md) -* [patricia-tree.md](fundamentals/mining.md) -* [rlp.md](fundamentals/rlp.md) -* [what-is-ethereum.md](fundamentals/what-is-ethereum.md) -* [mining](/mining) +* [enode-url-format.md](enode-url-format.md) +* [ethereum-introduction.md](ethereum-introduction.md) +* [getting-ether.md](getting-ether.md) +* [glossary.md](glossary.md) +* [mining.md](mining.md) +* [patricia-tree.md](mining.md) +* [rlp.md](rlp.md) +* [what-is-ethereum.md](what-is-ethereum.md) +* [mining](mining.md) diff --git a/fundamentals/getting-started.md b/fundamentals/getting-started.md index 6a84be3..1cb4d14 100644 --- a/fundamentals/getting-started.md +++ b/fundamentals/getting-started.md @@ -3,7 +3,7 @@ For an introduction to Ethereum, see the [beginners](https://ethereum.org/beginners/) section of ethereum.org. -For an introduction targeted see [Ethereum introduction](./fundamentals/ethereum-introduction.md). If you want to get a deeper understanding, start by reading the [whitepaper](https://ethereum.org/whitepaper) and the [design rationale](./design-rationale.md). For a more formal review, read the [yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf). If you are interested in being a core developer, find a project that interests you, and start contributing to that (maybe pro-bono initially, until maintainers like you and decide to hire you). +For an introduction targeted see [Ethereum introduction](./ethereum-introduction.md). If you want to get a deeper understanding, start by reading the [whitepaper](https://ethereum.org/whitepaper) and the [design rationale](./design-rationale.md). For a more formal review, read the [yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf). If you are interested in being a core developer, find a project that interests you, and start contributing to that (maybe pro-bono initially, until maintainers like you and decide to hire you). If you are interested in developing smart contracts you can see [here](https://en.wikipedia.org/wiki/Ethereum#Programming_languages), as well as under [ÐApp Development](./dapp-development.md) (which is also in the sidebar). diff --git a/fundamentals/mining.md b/fundamentals/mining.md index c8ccdc8..520d655 100644 --- a/fundamentals/mining.md +++ b/fundamentals/mining.md @@ -18,13 +18,13 @@ Ethereum Frontier, like all blockchain technologies uses an incentive-driven mod Miners produce blocks which the others check for validity. Among other well-formedness criteria, a block is only valid if it contains **proof of work** (PoW) of a given **difficulty**. Note that in Ethereum 1.1, this is likely going to be replaced by a **proof of stake** model. -The proof of work algorithm used is called [Ethash](./../ethash.md) (a modified version of [Dagger-Hashimoto](./../glossary/dagger-hashimoto.md)) involves finding a nonce input to the algorithm so that the result is below a certain threshold depending on the difficulty. The point in PoW algorithms is that there is no better strategy to find such a nonce than enumerating the possibilities while verification of a solution is trivial and cheap. If outputs have a uniform distribution, then we can guarantee that on average the time needed to find a nonce depends on the difficulty threshold, making it possible to control the time of finding a new block just by manipulating difficulty. +The proof of work algorithm used is called [Ethash](../concepts/ethash/ethash.md) (a modified version of [Dagger-Hashimoto](../concepts/dagger-hashimoto.md)) involves finding a nonce input to the algorithm so that the result is below a certain threshold depending on the difficulty. The point in PoW algorithms is that there is no better strategy to find such a nonce than enumerating the possibilities while verification of a solution is trivial and cheap. If outputs have a uniform distribution, then we can guarantee that on average the time needed to find a nonce depends on the difficulty threshold, making it possible to control the time of finding a new block just by manipulating difficulty. The difficulty dynamically adjusts so that on average one block is produced by the entire network every 12 seconds (ie., 12 s block time). This heartbeat basically punctuates the synchronisation of system state and guarantees that maintaining a fork (to allow double spend) or rewriting history is impossible unless the attacker possesses more than half of the network mining power (so called 51% attack). Any node participating in the network can be a miner and their expected revenue from mining will be directly proportional to their (relative) mining power or **hashrate**, ie., number of nonces tried per second normalised by the total hashrate of the network. -Ethash PoW is memory hard, making it basically ASIC resistant. This means that calculating the PoW requires choosing subsets of a fixed resource dependent on the nonce and block header. This resource (a few gigabyte size data) is called a **DAG** (directed acyclic graph). The [DAG](./../ethash/dag.md) is totally different every 30000 blocks (a 100 hour window, called an **epoch**) and takes a while to generate. Since the DAG only depends on block height, it can be pregenerated but if it is not, the client need to wait the end of this process to produce a block. Until clients actually precache DAGs ahead of time the network may experience a massive block delay on each epoch transition. Note that the DAG does not need to be generated for verifying the PoW essentially allowing for verification with both low CPU and small memory. +Ethash PoW is memory hard, making it basically ASIC resistant. This means that calculating the PoW requires choosing subsets of a fixed resource dependent on the nonce and block header. This resource (a few gigabyte size data) is called a **DAG** (directed acyclic graph). The [DAG](../concepts/ethash/dag.md) is totally different every 30000 blocks (a 100 hour window, called an **epoch**) and takes a while to generate. Since the DAG only depends on block height, it can be pregenerated but if it is not, the client need to wait the end of this process to produce a block. Until clients actually precache DAGs ahead of time the network may experience a massive block delay on each epoch transition. Note that the DAG does not need to be generated for verifying the PoW essentially allowing for verification with both low CPU and small memory. As a special case, when you start up your node from scratch, mining will only start once the DAG is built for the current epoch. @@ -59,7 +59,7 @@ For instance `geth makedag 360000 ~/.ethash`. Note that ethash uses `~/.ethash` # The Algorithm -Our algorithm, [Ethash](./../ethash.md) (previously known as Dagger-Hashimoto), is based around the provision of a large, transient, randomly generated dataset which forms a DAG (the Dagger-part), and attempting to solve a particular constraint on it, partly determined through a block's header-hash. +Our algorithm, [Ethash](../concepts/ethash/ethash.md) (previously known as Dagger-Hashimoto), is based around the provision of a large, transient, randomly generated dataset which forms a DAG (the Dagger-part), and attempting to solve a particular constraint on it, partly determined through a block's header-hash. It is designed to hash a fast verifiability time within a slow CPU-only environment, yet provide vast speed-ups for mining when provided with a large amount of memory with high-bandwidth. The large memory requirements mean that large-scale miners get comparatively little super-linear benefit. The high bandwidth requirement means that a speed-up from piling on many super-fast processing units sharing the same memory gives little benefit over a single unit. @@ -81,4 +81,4 @@ An sgminer module for Ethash is expected to be released at some point during, bu Communication between the external mining application and the Ethereum daemon for work provision and submission happens through the JSON-RPC API. Two RPC functions are provided; `eth_getWork` and `eth_submitWork`. -These are formally documented on the [JSON-RPC API](./../json-rpc.md) wiki article. +These are formally documented on the [JSON-RPC API](../json-rpc/api.md) wiki article. diff --git a/governance/maintainers.md b/governance/maintainers.md index 573ea6d..d8e3f05 100755 --- a/governance/maintainers.md +++ b/governance/maintainers.md @@ -12,7 +12,7 @@ The [wiki home page](/) has links to some of these items. The purpose of this pa | Interfaces Repo | [ethereum/interfaces](https://github.com/ethereum/interfaces) | UNKNOWN | | | Light Ethereum Subprotocol (LES) - protocol to support light nodes of mobile, embedded, and other low resource clients | [zsfelfoldi/go-ethereum/wiki](https://github.com/zsfelfoldi/go-ethereum/wiki/Light-Ethereum-Subprotocol-%28LES%29) | [zsfelfoldi](https://github.com/zsfelfoldi) | See the local wiki page [Light-client-protocol](Light-client-protocol) for more info | | Whisper - a communication protocol for DApps to communicate with each other | [go-ethereum/wiki Whisper v6 RPC API](https://github.com/ethereum/go-ethereum/wiki/Whisper-v6-RPC-API) | UNKNOWN | Local wiki pages [Whisper](Whisper) & [Whisper Overview](Whisper-Overview) are from go-ethereum/wiki | -| Swarm | [go-ethereum/2959](https://github.com/ethereum/go-ethereum/pull/2959) | UNKNOWN | See local wiki page [Swarm Hash](/glossary/swarm-hash) & [original 2015 info on go-ethereum/wiki](https://github.com/ethereum/go-ethereum/wiki/Swarm---distributed-preimage-archive) & maybe [ethereum/wiki/Distributed-Preimage-Archive](./distributed-preimage-archive.md) | +| Swarm | [go-ethereum/2959](https://github.com/ethereum/go-ethereum/pull/2959) | UNKNOWN | See local wiki page [Swarm Hash](/glossary/swarm-hash) & [original 2015 info on go-ethereum/wiki](https://github.com/ethereum/go-ethereum/wiki/Swarm---distributed-preimage-archive) & maybe [ethereum/wiki/Distributed-Preimage-Archive](../ideas/distributed-preimage-archive.md) | [^jsonrpc]: The JSON-RPC spec is stale / unmaintained. [EIP-1474 has been merged as draft](http://eips.ethereum.org/EIPS/eip-1474), and some work to have a separate spec repo here [ethereum-json-rpc-spec](https://github.com/spadebuilders/ethereum-json-rpc-spec). [bitpshr](https://github.com/bitpshr) has volunteered to be a maintainer. diff --git a/governance/polices-and-guidelines.md b/governance/polices-and-guidelines.md index bff9206..3b3939a 100755 --- a/governance/polices-and-guidelines.md +++ b/governance/polices-and-guidelines.md @@ -8,7 +8,7 @@ tags: # Index of Pages -* [design-rationale.md](/policies-and-guidelines/design-rationale.md) -* [governance-compendium.md](/policies-and-guidelines/governance-compendium.md) +* [design-rationale.md](../fundamentals/design-rationale.md) +* [governance-compendium.md](governance-compendium.md) diff --git a/howto/ethereum-development-tutorial.md b/howto/ethereum-development-tutorial.md index 3ccb4c2..6cb7041 100644 --- a/howto/ethereum-development-tutorial.md +++ b/howto/ethereum-development-tutorial.md @@ -175,4 +175,4 @@ To get early traffic to your Ðapp, you can submit your Ðapp to [Dapp Insight]( ## Fine Points To Keep Track Of -See [subtleties](./../subtleties.md) +See [subtleties](../faqs/subtleties.md) diff --git a/research/alternative-blockchains-randomness-economics-and-other-research-topics.md b/research/alternative-blockchains-randomness-economics-and-other-research-topics.md index 0413bf3..1cdf610 100644 --- a/research/alternative-blockchains-randomness-economics-and-other-research-topics.md +++ b/research/alternative-blockchains-randomness-economics-and-other-research-topics.md @@ -37,7 +37,7 @@ Cryptocurrencies](https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYw ### Ziliqa -[Ziliqa](https://docs.zilliqa.com/whitepaper.pdf): a PoW sharded architecture consisting of a dataflow smart contract layer, and 5 other layers. Uses the EC-Schnorr multiginature signature scheme. However, RANDAO is preferable to aggregate/multisignature schemes since it is not prone to a 51% attack. Also uses committees, as is planned with Dfinity and Ethereum, although here the committees manage how miners are assigned to shards, whereas in Ethereum that is the task of the beacon chain and the sharding manager contract on the main chain. Uses PBFT consensus, which doesn't seem to be as good as [Casper](./casper-proof-of-stake-compendium.md) [FFG](https://eips.ethereum.org/EIPS/eip-1011), which is also used with PoW. +[Ziliqa](https://docs.zilliqa.com/whitepaper.pdf): a PoW sharded architecture consisting of a dataflow smart contract layer, and 5 other layers. Uses the EC-Schnorr multiginature signature scheme. However, RANDAO is preferable to aggregate/multisignature schemes since it is not prone to a 51% attack. Also uses committees, as is planned with Dfinity and Ethereum, although here the committees manage how miners are assigned to shards, whereas in Ethereum that is the task of the beacon chain and the sharding manager contract on the main chain. Uses PBFT consensus, which doesn't seem to be as good as [Casper](../concepts/casper-proof-of-stake-compendium.md) [FFG](https://eips.ethereum.org/EIPS/eip-1011), which is also used with PoW. ### EOS diff --git a/roadmap/releases.md b/roadmap/releases.md index f1c19c6..6ca3cb2 100755 --- a/roadmap/releases.md +++ b/roadmap/releases.md @@ -11,9 +11,9 @@ While still valid, the substance behind Ethereum has changed, and will continue - **Release step 2.0: Homestead**, launched 14 March 2016 (Pi Day) at block number 1,150,000 as announced [here](https://blog.ethereum.org/2016/02/29/homestead-release/). For changes in the Homestead release, see [this EIP](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md). Homestead marked the exit from a beta product to a stable release. - **Release step 2.1: DAO Hard Fork** - **Release step 2.2: Tangerine Whistle**, aka Anti-DoS, EIP 150 -- **Release step 2.3: Spurious Dragon**, aka State-clearing, EIP 158/161, was released in Nov 2016. Spurious Dragon is aiming for [Dapp developers](./dapp-developer-resources.md) as well as end users for limited categories of applications, and had a number of security enhancements. -- **Release Step 3.0: Metropolis phase 1: Byzantium**, October 16 2017 as announced [here](https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/). Byzantium aims to introduce various privacy and functionality improvements. Details are [here](https://github.com/ethereum/EIPs#accepted-eips-planned-for-adoption-in-the-byzantium-metropolis-hard-fork). For the Byzantium Hard Fork, refer to [here](https://web.archive.org/web/20171026151615/https://github.com/ethereum/EIPs#accepted-eips-planned-for-adoption-in-the-byzantium-metropolis-hard-fork), which is an archive link showing the Byzantium EIPs. Also, refer to [here](./byzantium-hard-fork-changes.md) for a quick summary of Byzantium EIPs. +- **Release step 2.3: Spurious Dragon**, aka State-clearing, EIP 158/161, was released in Nov 2016. Spurious Dragon is aiming for [Dapp developers](../fundamentals/dapp-developer-resources.md) as well as end users for limited categories of applications, and had a number of security enhancements. +- **Release Step 3.0: Metropolis phase 1: Byzantium**, October 16 2017 as announced [here](https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/). Byzantium aims to introduce various privacy and functionality improvements. Details are [here](https://github.com/ethereum/EIPs#accepted-eips-planned-for-adoption-in-the-byzantium-metropolis-hard-fork). For the Byzantium Hard Fork, refer to [here](https://web.archive.org/web/20171026151615/https://github.com/ethereum/EIPs#accepted-eips-planned-for-adoption-in-the-byzantium-metropolis-hard-fork), which is an archive link showing the Byzantium EIPs. Also, refer to [here](../roadmap/byzantium-hard-fork-changes.md) for a quick summary of Byzantium EIPs. - **Release Step 3.1: Metropolis phase 2: Constantinople**, TBA, expected in 2018. Details on Metropolis are [here](https://github.com/ethereum/EIPs#deferred-eips-adoption-postponed-until-the-constantinople-metropolis-hard-fork). [This archive link lists the deferred Constantinople EIPs](https://web.archive.org/web/20180103233351/https://github.com/ethereum/EIPS#deferred-eips-adoption-postponed-until-the-constantinople-metropolis-hard-fork). This is an archive link in case the EIPs list is changed in a way that does not breakdown EIPs into different releases, as is the case up until now. -- **Release Step Four: Serenity**, TBA. Serenity is meant to move from consensus through [Proof-of-Work](Ethash) to [Proof-of-Stake](./proof-of-stake-faqs.md). Details are [here](https://blog.ethereum.org/2016/03/05/serenity-poc2/) and [here](https://blog.ethereum.org/2015/12/24/understanding-serenity-part-i-abstraction/), although the second post seems outdated as abstraction has moved forward to Constantinople. +- **Release Step Four: Serenity**, TBA. Serenity is meant to move from consensus through [Proof-of-Work](Ethash) to [Proof-of-Stake](../concepts/proof-of-stake-faqs.md). Details are [here](https://blog.ethereum.org/2016/03/05/serenity-poc2/) and [here](https://blog.ethereum.org/2015/12/24/understanding-serenity-part-i-abstraction/), although the second post seems outdated as abstraction has moved forward to Constantinople. - For other changes, refer to the [the finalized list of EIPs](https://github.com/ethereum/EIPS#finalized-eips-standards-that-have-been-adopted). -- Further releases will focus on massive scalability increases through sharding as well as virtual machine improvements and other features, as detailed [here](./wishlist.md). +- Further releases will focus on massive scalability increases through sharding as well as virtual machine improvements and other features, as detailed [here](../concepts/wishlist.md). diff --git a/scalability/chain-fibers-redux.md b/scalability/chain-fibers-redux.md index aed80d0..159afd2 100644 --- a/scalability/chain-fibers-redux.md +++ b/scalability/chain-fibers-redux.md @@ -1,6 +1,6 @@ # Chain Fibers Redux -_This article describes a scalability proposal made by Gavin Wood in 2015. Many of the principles described here have been a key inspiration for subsequent "[sharding](./sharding-faqs.md)" proposals._ +_This article describes a scalability proposal made by Gavin Wood in 2015. Many of the principles described here have been a key inspiration for subsequent "[sharding](../sharding/sharding-faqs.md)" proposals._ ## Blockchain Scalability: Chain-Fibers Redux diff --git a/sharding/Sharding-FAQs.md b/sharding/Sharding-FAQs.md index 893aa35..75a9bba 100644 --- a/sharding/Sharding-FAQs.md +++ b/sharding/Sharding-FAQs.md @@ -45,9 +45,9 @@ In the event of a large attack on [Plasma](https://www.plasma.io) subchains, all Note that there is one design that states that: "Given a malicious operator (the worst case), the system degrades to an on-chain token. A malicious operator cannot steal funds and cannot deprive people of their funds for any meaningful amount of time."—. See also [here](https://twitter.com/PhABCD/status/1090090236380626944) for related information. -[State channels](http://www.jeffcoleman.ca/state-channels/) have similar properties, though with different tradeoffs between versatility and speed of finality. Other layer 2 technologies include [TrueBit](https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf) off-chain interactive verification of execution and [Raiden](https://raiden.network/), which is another organisation working on state channels. [Proof of stake](./proof-of-stake-faqs.md) with Casper (which is layer 1) would also improve scaling—it is more decentralizable, not requiring a computer that is able to mine, which tends towards centralized mining farms and institutionalized mining pools as difficulty increases and the size of the state of the blockchain increases. +[State channels](http://www.jeffcoleman.ca/state-channels/) have similar properties, though with different tradeoffs between versatility and speed of finality. Other layer 2 technologies include [TrueBit](https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf) off-chain interactive verification of execution and [Raiden](https://raiden.network/), which is another organisation working on state channels. [Proof of stake](../concepts/proof-of-stake-faqs.md) with Casper (which is layer 1) would also improve scaling—it is more decentralizable, not requiring a computer that is able to mine, which tends towards centralized mining farms and institutionalized mining pools as difficulty increases and the size of the state of the blockchain increases. -Sharding is different to state channels and Plasma in that periodically notaries are pseudo-randomly assigned to vote on the validity of collations (analogous to blocks, but without an EVM state transition function in phase 1), then these collations are accepted into the main chain after the votes are verified by a committee on the main chain, via a sharding manager contract on the main chain. In phase 5 (see the [roadmap](./sharding-roadmap.md) for details), shards are tightly coupled to the main chain, so that if any shard or the main chain is invalid, the whole network is invalid. There are other differences between each mechanism, but at a high level, Plasma, state channels and Truebit are off-chain for an indefinite interval, connect to the main chain at the smart contract, layer 2 level, while they can draw back into and open up from the main chain, whereas shards are regularly linked to the main chain via consensus in-protocol. +Sharding is different to state channels and Plasma in that periodically notaries are pseudo-randomly assigned to vote on the validity of collations (analogous to blocks, but without an EVM state transition function in phase 1), then these collations are accepted into the main chain after the votes are verified by a committee on the main chain, via a sharding manager contract on the main chain. In phase 5 (see the [roadmap](../sharding/sharding-roadmap.md) for details), shards are tightly coupled to the main chain, so that if any shard or the main chain is invalid, the whole network is invalid. There are other differences between each mechanism, but at a high level, Plasma, state channels and Truebit are off-chain for an indefinite interval, connect to the main chain at the smart contract, layer 2 level, while they can draw back into and open up from the main chain, whereas shards are regularly linked to the main chain via consensus in-protocol. See also [these tweets from Vlad](https://twitter.com/VladZamfir/status/1001447804219346945). @@ -155,7 +155,7 @@ Now, let’s look at the risk of attacks being made that try to influence the ra Due to the [central limit theorem](https://en.wikipedia.org/wiki/Central_limit_theorem), the standard deviation of the number of samples, and based [on other known results in math](http://math.stackexchange.com/questions/89030/expectation-of-the-maximum-of-gaussian-random-variables) the expected maximum of N random samples is slightly under M + S \* sqrt(2 \* log(N)) where M is the mean and S is the standard deviation. Hence the reward for manipulating the randomness and effectively re-rolling the dice (i.e. increasing N) drops off sharply, e.g. with 0 re-trials your expected reward is $100, with one re-trial it's $105.5, with two it's $108.5, with three it's $110.3, with four it's $111.6, with five it's $112.6 and with six it's $113.5. Hence, after five retrials it stops being worth it. As a result, an economically motivated attacker with ten percent of stake will (socially wastefully) spend $5 to get an additional revenue of $13, for a net surplus of $8. -However, this kind of logic assumes that one single round of re-rolling the dice is expensive. Many older proof of stake algorithms have a “stake grinding” vulnerability where re-rolling the dice simply means making a computation locally on one’s computer; algorithms with this vulnerability are certainly unacceptable in a sharding context. Newer algorithms (see the “validator selection” section in the [proof of stake FAQ](./proof-of-stake-faqs.md)) have the property that re-rolling the dice can only be done by voluntarily giving up one’s spot in the block creation process, which entails giving up rewards and fees. The best way to mitigate the impact of marginal economically motivated attacks on sample selection is to find ways to increase this cost. One method to increase the cost by a factor of sqrt(N) from N rounds of voting is the [majority-bit method devised by Iddo Bentov](https://arxiv.org/pdf/1406.5694.pdf). +However, this kind of logic assumes that one single round of re-rolling the dice is expensive. Many older proof of stake algorithms have a “stake grinding” vulnerability where re-rolling the dice simply means making a computation locally on one’s computer; algorithms with this vulnerability are certainly unacceptable in a sharding context. Newer algorithms (see the “validator selection” section in the [proof of stake FAQ](../concepts/proof-of-stake-faqs.md)) have the property that re-rolling the dice can only be done by voluntarily giving up one’s spot in the block creation process, which entails giving up rewards and fees. The best way to mitigate the impact of marginal economically motivated attacks on sample selection is to find ways to increase this cost. One method to increase the cost by a factor of sqrt(N) from N rounds of voting is the [majority-bit method devised by Iddo Bentov](https://arxiv.org/pdf/1406.5694.pdf). Another form of random number generation that is not exploitable by minority coalitions is the deterministic threshold signature approach most researched and advocated by Dominic Williams. The strategy here is to use a [deterministic threshold signature](https://eprint.iacr.org/2002/081.pdf) to generate the random seed from which samples are selected. Deterministic threshold signatures have the property that the value is guaranteed to be the same regardless of which of a given set of participants provides their data to the algorithm, provided that at least ⅔ of participants do participate honestly. This approach is more obviously not economically exploitable and fully resistant to all forms of stake-grinding, but it has several weaknesses: @@ -357,4 +357,4 @@ Abstracting the execution engine or allowing multiple execution engines to exist 14. Thanks to Justin Drake for pointing me to cryptographic accumulators, as well as [this paper](https://eprint.iacr.org/2009/612.pdf) that gives the argument for the impossibility of sublinear batching. See also this thread: -Further reading related to sharding, and more generally scalability and research, is available [here](./sharding-introduction-r-d-compendium.md) and [here](./rd.md). +Further reading related to sharding, and more generally scalability and research, is available [here](./sharding-introduction-r-d-compendium.md) and [here](../research/rd.md).