diff --git a/assets/img/7-Polkadot/eco/jam-clients.png b/assets/img/7-Polkadot/eco/jam-clients.png new file mode 100644 index 000000000..15c8a82ae Binary files /dev/null and b/assets/img/7-Polkadot/eco/jam-clients.png differ diff --git a/assets/img/7-Polkadot/eco/wallets.png b/assets/img/7-Polkadot/eco/wallets.png new file mode 100644 index 000000000..55f9eabd3 Binary files /dev/null and b/assets/img/7-Polkadot/eco/wallets.png differ diff --git a/assets/img/7-Polkadot/staking-rate.png b/assets/img/7-Polkadot/staking-rate.png index f4bc4d3b2..f102d3152 100644 Binary files a/assets/img/7-Polkadot/staking-rate.png and b/assets/img/7-Polkadot/staking-rate.png differ diff --git a/syllabus/7-Polkadot/5-data-sharding-and-data-availability-slides.md b/syllabus/7-Polkadot/5-data-sharding-and-data-availability-slides.md index 59f24239c..a387faeee 100644 --- a/syllabus/7-Polkadot/5-data-sharding-and-data-availability-slides.md +++ b/syllabus/7-Polkadot/5-data-sharding-and-data-availability-slides.md @@ -1,5 +1,5 @@ --- -title: Data Availability and Data Sharding Deep Dive +title: Data Availability and Data Sharding description: Data Availability Problem, Erasure coding, Data sharding. duration: 1h owner: Bradley Olson @@ -23,23 +23,30 @@ owner: Bradley Olson --- -## What Data Needs Availability? +## What Data Needs Offchain Availability? -Sharded Permanent Record: **Parachains!** +Sharded Permanent Record? ❌ **Parachains!** -Condensed Permanent Record: **Relay Chain!** +Condensed Permanent Record? ❌ **Relay Chain!** -Comprehensive 24 Hour Record: **Polkadot DA!** + + +Comprehensive 24 Hour Record? ✅ **Polkadot DA!** + + Notes: -- Most data live solely on parachains +- Most permanent data live solely on parachains - Condensed data, hashes and commitments, stored on relay chain -- DA secures heavy (MBs) information critical to the secure progression of parachains. Should be dropped from validators when old. +- Polkadot DA secures proofs of validity. PoV's contain information critical to the secure progression of parachains. These are dropped from validators when old. +- Way too large for on-chain storage! + - All other data added to relay chain per day: ~555M + - 40 PoVs per block for a day: ~72G --- @@ -52,13 +59,10 @@ Incorrectness can be proven (merkle proofs), but unavailability can't. Notes: - You can't just hold a small number of nodes accountable for making some data available -- Needs an off chain solution! - - All other data added to relay chain per day: ~555M - - 40 PoVs per block for a day: ~72G --- -### Data Availability Problem: Parachains +### Vulnerabilities With No DA: Malicious Collator
@@ -79,19 +83,19 @@ Solution: --- -### Data Availability Problem: Relay Chain +### Vulnerabilities With No DA: Malicious Backers Notes: -- Malicious backers could distribute invalid PoV to only malicious approval checkers +- Malicious backers could distribute invalid PoV selectively to malicious approval checkers or not at all - Really bad - It means attackers could consistently finalize invalid parachain blocks with just a hand full of dishonest approval checkers --- -### Data Availability Problem: Relay Chain +### Vulnerabilities With No DA: Malicious Backers @@ -132,12 +136,14 @@ Notes: - Minimal unit of Polkadot execution scheduling -- At most 1 candidate pending availability per relay block, per core +- Cores abstract over several processing and storage resources -- Considered "occupied" while a candidate paired with that core is pending availability +- At most 1 candidate pending availability per relay block, per core -- It saves resources to bundle signals about availability for all cores together +- Considered "occupied" while a candidate paired with that core is pending availability +- It saves resources to bundle signals about availability for all cores together + @@ -147,6 +153,14 @@ Notes: +Notes: + +- Cores abstract over + - Backing processing + - DA processing + - DA storage + - On-Chain Inclusion + --- ### Laying the Foundation: Erasure Coding @@ -333,6 +347,8 @@ For any number $n$ of points $(x_i,y_i)$ there exists only one polynomial of deg Notes: +- We can mathematically derive the interpolating polynomial for any set of points. + Question: What are x_i and y_i wrt to our data? --- diff --git a/syllabus/7-Polkadot/6-cumulus-deep-dive-slides.md b/syllabus/7-Polkadot/6-cumulus-deep-dive-slides.md index d6c7d8c4f..bdeea8909 100644 --- a/syllabus/7-Polkadot/6-cumulus-deep-dive-slides.md +++ b/syllabus/7-Polkadot/6-cumulus-deep-dive-slides.md @@ -52,7 +52,8 @@ Notes: - Substrate is a blockchain building framework - But only "solo" chains - Split into runtime/node side -- Both Polkadot and Cumulus extend substrate +- Polkadot is built using substrate +- Cumulus extends substrate to allow any substrate chain to operate as a parachain - Polkadot provides APIs to collators --- @@ -140,12 +141,12 @@ Notes: --- -### Import Driven Block Authoring +### Key Process 1: Import Driven Block Authoring -Collators are responsible for authoring new blocks, and they do so when importing relay blocks. +Collators are responsible for authoring new blocks. Prior to the rollout of asynchronous backing, they did so when importing relay blocks. Honest Collators will choose to author blocks descending from the best head. -```rust[|3|4-8|11] +```rust[3|4-8|11] // Greatly simplified loop { let imported = import_relay_chain_blocks_stream.next().await; @@ -165,19 +166,17 @@ loop { Notes: -- `parachain_trigger_block_authoring` itself can decide if it wants to build a block. -- e.g. the parachain having a block time of 30 seconds -- With asynchronous backing, parachain block authoring is untethered from relay block import. +- With asynchronous backing, parachain block authoring is untethered from relay block import, though still ultimately reliant on it. --- -### Finality +### Key Process 2: Finality Updates To facilitate shared security, parachains inherit their finality from the relay chain.
-```rust[|3|4-8|11] +```rust[3|4-8|11] // Greatly simplified loop { let finalized = finalized_relay_chain_blocks_stream.next().await; @@ -194,9 +193,9 @@ loop { --- -### Ensuring Block Availability +### Key Process 3: Ensuring Block Availability -As a part of the parachains protocol, Polkadot makes parachain blocks available for several hours after they are backed. +As a part of the parachains protocol, Polkadot makes parachain blocks available for 24 hours after they are backed.

@@ -206,13 +205,13 @@ As a part of the parachains protocol, Polkadot makes parachain blocks available - Malicious collator +

+ +> What role does cumulus play? Notes: -- Approvers need the PoV to validate -- Can't just trust backers to distribute the PoV faithfully -- Malicious or faulty collators may advertise collations to validators without sharing them with other parachain nodes. -- Cumulus is responsible for requesting missing blocks in the latter case +- When Cumulus learns of a new parachain block via a receipt on the relay chain, it is responsible for deciding how long to wait before deciding that the block is missing and then requesting it from Polkadot DA. --- @@ -252,14 +251,12 @@ Notes: --- -# Collation Generation and Advertisement +# Key Process 4: Collation Generation and Advertisement --- ## Collation Generation -The last of our key processes - 1. Relay node imports block in which parachain's avail. core was vacated @@ -282,27 +279,9 @@ The last of our key processes Notes: -- First, sent to tethered relay node `CollationGeneration` subsystem to be repackaged and forwarded to backers -- At least one backer responds, signing its approval -- Triggers gossip of candidate to parachain node import queues - ---- - -#### Distribution in Code - -```rust[1|5] -let result_sender = self.service.announce_with_barrier(block_hash); - -tracing::info!(target: LOG_TARGET, ?block_hash, "Produced proof-of-validity candidate.",); - -Some(CollationResult { collation, result_sender: Some(result_sender) }) -``` - -Notes: - -- Prepares the announcement of a new parablock to peers with "announce_with_barrier" -- Waits for green light from validator by sending it a "result_sender" -- When validator sends positive result through sender, then the collator announces the block +- New parablocks are communicated simultaneously in two ways + - A collation is sent to the collator's tethered relay node to be processed in the `CollationGeneration` subsystem. There it is repackaged before being forwarded to backers. + - An advertisement of the new parablock candidate is gossiped to parachain node import queues --- @@ -334,7 +313,7 @@ Notes: -- Building Blocks to make this possible, the PVF and PoV, are delivered within collations +- The building blocks to make this possible, the PVF and PoV, are delivered within collations @@ -394,7 +373,7 @@ The code is hashed and saved in the storage of the relay chain. Notes: -PVF not only contains the runtime, but also a function `validate_block` needed to interpret all the extra information in a PoV required for validation. +The function `validate_block` needed to interpret all the extra information in a PoV required for validation. This extra information is unique to each parachain and opaque to the relay chain. --- @@ -431,7 +410,7 @@ The input of the runtime validation process is the PoV, and the function called #### Validate Block in Code -```rust [2|3-4|6|8-11] +```rust [2|3-4|6|8-11|14] // Very simplified fn validate_block(input: InputParams) -> Output { // First let's initialize the state @@ -449,14 +428,14 @@ fn validate_block(input: InputParams) -> Output { } ``` -
- -> But where does `storage_proof` come from? - Notes: -We construct the sparse in-memory database from the storage proof and -then ensure that the storage root matches the storage root in the `parent_head`. +1. We construct the sparse in-memory database from the storage proof and then ensure that the storage root matches the storage root in the `parent_head`. +2. Replace host functions +3. Execute block +4. Create output. We check whether the `storage_root` and other outputs resulting from validation matched the commitments made by the collator. + +But where does `storage_proof` come from? --- @@ -496,18 +475,20 @@ Notes: Code highlighting: -- CandidateCommitments: Messages passed upwards, Downward messages processed, New code (checked against validation outputs) -- head_data & PoV (the validation inputs) +- CandidateCommitments: Messages passed upwards, Downward messages processed, New code, `head_data` (checked against validation outputs) +- PoV (the validation input) --- -### Proof of Validity (Witness Data) +### Witness Data (Storage Proof) +- Makes up most if the information in a PoV - Acts as a replacement for the parachain's pre-state for the purpose of validating a single block -- It allows the reconstruction of a sparse in-memory merkle trie -- State root can then be compared to that from parent header +- It enables the construction of a sparse in-memory merkle trie +- State root can then be compared to that from parent header + --- @@ -537,9 +518,9 @@ Notes: --- -#### Parablock Validation in Summary +#### Witness Data in Validation -```rust [2|3-4|6] +```rust [4] // Very simplified fn validate_block(input: InputParams) -> Output { // First let's initialize the state @@ -557,10 +538,10 @@ fn validate_block(input: InputParams) -> Output { } ``` -- Now we know where the **storage_proof** comes from! +- Now we know where the **storage_proof** (witness data) comes from! - into_state constructs our storage trie -- Host functions written to access this new storage +- Host functions rewritten to access this new storage --- @@ -571,21 +552,23 @@ fn validate_block(input: InputParams) -> Output { - Every Substrate blockchain supports runtime upgrades +- Every time a validator wants to validate a parablock, it must first compile the PVF + ##### Problem - + - What happens if PVF compilation takes too long? - + - Approval no-shows - In disputes neither side may reach super-majority - + > Updating a Parachain runtime is not as easy as updating a standalone blockchain runtime - + @@ -595,12 +578,10 @@ fn validate_block(input: InputParams) -> Output { The relay chain needs a fairly hard guarantee that PVFs can be compiled within a reasonable amount of time. - -
- Collators execute a runtime upgrade but it is not applied -- Collators send the new runtime code to the relay chain in a collation +- Code sent in collation `Option` - The relay chain executes the **PVF Pre-Checking Process** - The first parachain block to be included after the end of the process applies the new runtime @@ -618,17 +599,30 @@ https://github.com/paritytech/cumulus/blob/master/docs/overview.md#runtime-upgra ##### PVF Pre-Checking Process + + +- Track +- Check + +- Vote + +- Conclude + +- Upgrade + +- Notify + + + + +Notes: + - The relay chain keeps track of all the new PVFs that need to be checked - Each validator checks if the compilation of a PVF is valid and does not require too much time, then it votes - - binary vote: accept or reject - - Super majority concludes the vote - - The new PVF replaces the prior one in relay chain state - - -Notes: +- A "go ahead" signal is sent, telling the parachain to apply the upgrade reference: https://paritytech.github.io/polkadot/book/pvf-prechecking.html diff --git a/syllabus/7-Polkadot/7-asynchronous-backing-slides.md b/syllabus/7-Polkadot/7-asynchronous-backing-slides.md index 62e3b0809..c6796ca46 100644 --- a/syllabus/7-Polkadot/7-asynchronous-backing-slides.md +++ b/syllabus/7-Polkadot/7-asynchronous-backing-slides.md @@ -39,15 +39,13 @@ Lets get to it -> How is this synchronous? - - - Notes: -- The dividing line between the left and right is when a candidate is backed on chain -- Approvals, disputes, and finality don't immediately gate the production of farther candidates. - So we don't need to represent those steps in this model. +- In synchronous backing: Backing for block `N+1` starts after inclusion for block `N` is complete. Backing and inclusion cannot take place simultaneously for different candidates of the same parachain and neither can outpace the other. +- White arrows represent execution flow +- The tasks within each of these purple circles take place during the time of a single relay chain block. +- Why might each of these two groupings of tasks need its own relay block to execute? +- Approvals, disputes, and finality not represented. Why? --- @@ -61,14 +59,10 @@ Notes:
-> How is this asynchronous? - - - Notes: -- Our cache of parablock candidates allows us to pause just before that dividing line, on-chain backing -- Why is backing asynchronous in this diagram? +- Notice difference in white execution arrow. Backing repeats, looping over and over. How is this possible? +- Our cache of backable parablock candidates allows inclusion to loop independently --- @@ -143,6 +137,7 @@ Image version 1: Image version 3: +- The execution context for a new parablock requires its parablock parent and relay parent - Whole process is a cycle of duration 12 seconds (2 relay blocks). - No part of this cycle can be started for a second candidate of the same parachain until the first is included. @@ -194,7 +189,7 @@ Image version 3: Notes: -Limitation example, upward messages remaining before the relay chain would have to drop incoming messages from our parachain +Limitation example: upward messages remaining before the relay chain would have to drop incoming messages from our parachain --- @@ -251,7 +246,7 @@ Notes: - Fragment trees are rooted in relay chain active leaves - Fragment trees built per scheduled parachain at each leaf - Fragment trees may have 0 or more fragments representing potential parablocks making up possible futures for a parachain's state. -- Collation generation, passing, and seconding work has already been completed for each fragment. +- Collation generation and seconding work has already been completed for each fragment. --- @@ -265,8 +260,8 @@ Notes: Returning to our most basic diagram -- Q: Which structure did I leave out the name of for simplicity, and where should that name go in our diagram? -- Q: Which did I omit entirely? +- Q: Which parablock storage structure did I leave out the name of for simplicity, and where should that name go in our diagram? +- Q: Which parablock storage structure did I omit entirely? --- @@ -278,7 +273,7 @@ Notes: - What is exotic core scheduling? - Multiple cores per parachain - - Overlapping leases of many lengths + - Overlapping bulk coretime leases of varying lengths - Lease + On-demand - How does asynchronous backing help? - The unincluded segment is necessary to build 2 or more parablocks in a single relay block diff --git a/syllabus/7-Polkadot/9-polkadot-ecosystem-economy-slides.md b/syllabus/7-Polkadot/9-polkadot-ecosystem-economy-slides.md index e92928de9..bb05bf9e9 100644 --- a/syllabus/7-Polkadot/9-polkadot-ecosystem-economy-slides.md +++ b/syllabus/7-Polkadot/9-polkadot-ecosystem-economy-slides.md @@ -33,11 +33,13 @@ Unfortunately this presentation could never be fully exhaustive, but perhaps it
-The DOT token can be in one of the following states: +DOT is the native token of the Polkadot Network. + +DOT tokens can be in one of the following states: 1. Transferable -2. Locked (Frozen) -3. Reserved (Held) +2. Frozen (Locked) +3. Held (Reserved)
@@ -45,14 +47,14 @@ The DOT token can be in one of the following states: --- -## Reserved vs Locked Balance +## Frozen vs Held Balance -- New terms "Frozen" and "Held" are not quite used in Polkadot yet... +- Old terms "Reserved" and "Locked" are on their way out... - DOT in both states belong to the user... but cannot be spent / transferred. -- Reserved balances stack on top of one another. +- Held balances stack on top of one another. - Useful for user deposits, or other use cases where there is sybil concerns. - Ex: Deposit for storing data on-chain, -- Locked balances can overlap each other. +- Frozen balances can overlap each other. - Useful when you want to use the same tokens for multiple use cases. - Ex: Using the same tokens for both staking and voting in governance. @@ -94,6 +96,17 @@ The most bloat-ful storage on most blockchains are user accounts: --- +## Scaling with Data Sharding + +- Polkadot is already designed to scale by sharding data. + - Polkadot only needs to store the merkle root representing large amounts of data. +- The cost to store data on shards are orders of magnitude cheaper. + - We can have decreased storage deposits on these shards: + - ED: 1.0 DOT on Polkadot -> .01 DOT on Asset Hub + - Identity: 20 DOT on Polkadot -> .2 DOT on People Chain + +--- + ## DOT is a Utility Token
@@ -108,8 +121,8 @@ The most bloat-ful storage on most blockchains are user accounts: The DOT token serves multiple purposes to help the Polkadot network function: +- Purchasing Blockspace - Staking -- Bonding for Parachain Slots / Execution Cores - On-Chain Decision Making - Value Bearing for Trading / Using @@ -118,23 +131,6 @@ The DOT token serves multiple purposes to help the Polkadot network function: --- -## Ideal Usage of DOT Tokens - - - -Approximately... - -Model to be updated after Agile Coretime is live, as parachain slot auctions will be obsolete -and there are proposals to burn coretime revenue. - -Notes: - -- 50% Staking / Governance -- 30% Parachains -- 20% Tradable / Useable - ---- - ## DOT Inflation
@@ -149,7 +145,9 @@ Notes: DOT is currently configured to have a fixed inflation rate of 10% per year. -Newly minted tokens are distributed to stakers (validators / nominators) and the treasury. +Newly minted tokens are distributed to the treasury and stakers (validators / nominators). + +RFC for Flexible Inflation: https://github.com/polkadot-fellows/RFCs/pull/89
@@ -159,13 +157,12 @@ Newly minted tokens are distributed to stakers (validators / nominators) and the ## Ideal Staking Rate -We cannot force / tell users how to use their tokens, so we encourage "ideal" behavior by associating DOT token usage to how inflation is distributed. - -There’s a function that redirects some of the 10% inflation to the Treasury, instead of the stakers, when `ideal_rate != staking_rate`. - -Token holders are financially incentivized to maximize their staking returns, and thus distribute their tokens appropriately. - -[Ideal staking rate model to be revisited](https://forum.polkadot.network/t/adjusting-polkadots-ideal-staking-rate-calculation/3897) after parachain slot auctions are discontinued. +- We cannot force / tell users how to use their tokens. + - So we encourage "ideal" behavior by associating DOT token usage to how inflation is distributed. + - There’s a function that redirects staking inflation to the Treasury, instead of the stakers, when `ideal_rate != staking_rate`. + - Token holders are financially incentivized to maximize their staking returns, and thus distribute their tokens appropriately. +- Ideal Staking Rate is in the process of being adjusted since the introduction of coretime sales: + - https://forum.polkadot.network/t/adjusting-polkadots-ideal-staking-rate-calculation/3897 --- @@ -179,13 +176,27 @@ Token holders are financially incentivized to maximize their staking returns, an > > Black: Total Inflation vs Staking Rate +Notes: + +Blue line shows that: + +- When there is too little being staked, validators are encouraged to stake more. +- When there is too much being staked, validators are encouraged to stake less. + +Green line shows that validator APY goes down whenever more validators enter the staking system, that is unavoidable, but specifically past the ideal staking rate, the decrease in APY sharply decreases. + +Black line shows that inflation for for the whole network is fixed at 10%. + +The gap between the blue line and the black line shows the amount of inflation that is forwarded to the treasury, as compared to given to validators. +Event at the ideal staking rate, some percentage of the inflation is guaranteed to go to the treasury. + --- -## DOT Utility: Parachains +## DOT Utility: Purchasing Blockspace Polkadot provides many utilities, but arguably its most important utility is providing flexible, secure, and scalable blockspace. -Developers can purchase this blockspace as fixed-term or on-demand Parachains, **only** with the DOT token. +Developers can purchase this blockspace **only** with the DOT token.
@@ -193,25 +204,38 @@ Developers can purchase this blockspace as fixed-term or on-demand Parachains, * --- -## Expected Parachain Costs +## Evolution of the Blockspace Marketplace -Back of the napkin math: +
-- ~1 Billion DOT -- 30% Locked Up for Parachains = 300 Million -- ~100 Parachain = 3 Million DOT per Parachain Slot +
-At equilibrium... + -The costs of running parachains change significantly with Agile Coretime. +

---- + -## Parachain Economics Updates +
-There is a lot of ongoing discussion about updating the economics of Parachains. +
+ +- Initially blockspace was only sold in 2 year slots, in the form of Parachain auctions. +- We recently transitioned to agile coretime which allows more flexible access to blockspace. + - Coretime sales use periodic dutch auctions. +- JAM will continue to increase the flexibility of allocating and distributing blockspace. +- Exactly how blockspace is allocated and sold will continue to evolve over time. -Likely, these mechanics will update pretty soon, and continually over time. +
+ +
+ +Notes: + +- https://forum.polkadot.network/t/initial-coretime-pricing/5187 +- https://grillapp.net/12935/agile-coretime-pricing-explained-166522 +- https://www.youtube.com/watch?v=ci-h9zC-57Y +- https://twitter.com/rphmeier/status/1797339044893917397 --- @@ -227,7 +251,7 @@ Given the existence of a value bearing token, it can be used to provide security - Stakers are rewarded for good behavior, and punished for bad behavior. -- Punishments are aggressive enough that rational actors would never act maliciously. +- Punishment is designed to maximize the costs for a rational actor and thereby deter misbehavior. https://polkadot.network/features/staking/ @@ -366,22 +390,36 @@ For instance, a referendum proposed in this track needs to amass 48.2% support ( ## Governance Token Mechanics -- DOT tokens are locked when you vote on a proposal. -- You can reuse your locked tokens across multiple proposals. +- DOT tokens are frozen when you vote on a proposal. +- You can reuse your frozen tokens across multiple proposals. - Voting for one proposal does not affect your ability to vote on another proposal. -- You can also reuse staked tokens (which are also just locked). +- You can also reuse staked tokens (which are also just frozen). - You can update your vote while the proposal is ongoing. -- If you used conviction voting, your tokens might be locked for long periods of time passed the end of a proposal. +- If you used conviction voting, your tokens might be frozen for long periods of time passed the end of a proposal. --- ## Treasury +
+ +
+ Polkadot has an on-chain treasury which is used to support permissionless and decentralized development of the network. -Treasury gets its funds through inefficiencies in the inflation curve, slashing, and by taking 80% transaction fees. +- Treasury gets its funds through inflation, slashing, and by taking 80% transaction fees. + +- Treasury will automatically burn a 1% of its funds every spending period (24 days), placing pressure on spending the tokens. + +
+ +
-Treasury will automatically burn a 1% of its funds every spending period (24 days), placing pressure on spending the tokens. + + +
+ +
--- @@ -391,7 +429,7 @@ Treasury will automatically burn a 1% of its funds every spending period (24 day - Bounties: Multi-stage payments to individuals managed by governance and an appointed bounty curator. - Tips: Small payments to individuals that can be made more easily through specific governance tracks. -The Polkadot Treasury currently has over 33,000,000 DOT. +The Polkadot Treasury currently has over 22,000,000 DOT. (June 2024) --- @@ -399,57 +437,45 @@ The Polkadot Treasury currently has over 33,000,000 DOT. --- -## Alternative Polkadot Clients - -The main Polkadot Client is built using Rust in Substrate. +## A Future Full of Clients -However, other clients for Polkadot are under development: +The Web3 Foundation is allocating 10 Million DOT for creating a diverse ecosystem of Polkadot clients. -- Kagome (C++17): https://github.com/soramitsu/kagome -- Gossamer (Go): https://github.com/ChainSafe/gossamer + -Over time, this can help provide additional resilience to the network from software bugs. +This can help provide additional resilience to the network from software bugs. --- -## Types of Parachains - -- Polkadot System Chains -- Market Bought Parachains - -
- -Perhaps this list will grow once more agile core allocation systems are implemented. - ---- +## System Parachains -## System Chains - -- System parachains contain core Polkadot protocol features, on a parachain rather than the Relay Chain. -- Polkadot uses its own parallel execution scaling technology scale itself. -- System parachains remove transactions from the Relay Chain, allowing more Relay Chain blockspace to be used for Polkadot's primary purpose: validating parachains. -- System Chains are allocated by governance. +- System parachains contain core Polkadot protocol features, on a parachain rather than Polkadot itself. +- **Polkadot uses its own heterogenous sharded scaling technology to scale itself.** +- System parachains remove transactions from the main Polkadot chain, allowing it to allocate more blockspace to other services. +- System parachains are allocated blockspace by governance. Notes: -https://wiki.polkadot.network/docs/learn-system-chains +- https://wiki.polkadot.network/docs/learn-system-chains +- https://github.com/polkadot-fellows/RFCs/blob/34d26ff1aa343b0cc980afbf2f40c1d5b6a781ea/text/0032-minimal-relay.md --- -## Current and Future System Chains +## Current and Future System Parachains Current: - Asset Hub: Allows creation and registration of tokens (FT & NFTs). -- Collectives: Acts as a place for coordination of the Polkadot DAOs. - Bridge Hub: A chain for managing bridges to other networks. +- Coretime Chain: responsible for the sales of coretime. +- Collectives: Acts as a place for coordination of the Polkadot DAOs. - Encointer: A third-party built chain providing Proof of Personhood. +- People Chain: A chain for managing identity and Personhood. Future: -- Coretime Chain: responsible for the sales of coretime. -- Staking: Manage all the validator and nominator logic, rewards, etc... - Governance: Manage all the various proposals and tracks. +- Staking: Manage all the validator and nominator logic, rewards, etc... - Eventually everything... Notes: @@ -458,16 +484,18 @@ https://wiki.polkadot.network/docs/learn-system-chains --- -## Market Bought Parachains +## Market Bought Blockspace
-Anyone with a great idea, and access to DOT token, can launch a parachain on Polkadot. +Anyone with a great idea, and access to DOT token, can launch an application on Polkadot. Dozens of teams from around the world have already done that, and are taking advantage of the features that Polkadot provides. +With JAM, this will only get easier. +
@@ -522,27 +550,13 @@ https://substrate.io/ecosystem/projects/ Thanks to the treasury and Polkadot community, a number of different wallets have been developed across the ecosystem. -
- -| Wallet | Platforms | Staking and Nomination Pools | NFTs | Crowdloans | Ledger support | Governance | -| :-------------: | :-----------------------------------------: | :--------------------------: | :--: | :--------: | :------------: | :--------: | -| Enkrypt | Brave, Chrome, Edge, Firefox, Opera, Safari | No, No | Yes | No | Yes | No | -| PolkaGate | Brave, Chrome, Firefox, Edge | Yes, Yes | No | Yes | Yes | Yes | -| SubWallet | Brave, Chrome, Edge, Firefox, iOs, Android | Yes, Yes | Yes | Yes | Yes | No | -| Talisman | Brave, Chrome, Edge, Firefox | Yes, Yes | Yes | Yes | Yes | No | -| Fearless Wallet | Brave, Chrome, iOS, Android | Yes, Yes | No | No | No | No | -| Nova Wallet | iOS, Android | Yes, Yes | Yes | Yes | Yes | Yes | -| Polkawallet | iOS, Android | Yes, Yes | No | Yes | No | Yes | + -
- -Notes: - -TODO make more pretty with icons or other images +https://polkadot.network/ecosystem/wallets/ --- -## Ledger Support w/ Metadata +## Generic Ledger Support
@@ -562,13 +576,17 @@ Users can get clear visibility into the transactions they are signing, and perfo
+Notes: + +- https://forum.polkadot.network/t/polkadot-generic-ledger-app/4295 + --- ## Block Explorers - Polkadot-JS Apps Explorer - Polkadot dashboard block explorer. Supports dozens of other networks, including Kusama, Westend, and other remote or local endpoints. - Subscan - Blockchain explorer for Substrate chains. -- 3xpl.com - Fastest ad-free universal block explorer and JSON API with Polkadot support. +- 3xpl.com - Universal block explorer and JSON API with Polkadot support. - Blockchair.com - Universal blockchain explorer and search engine with Polkadot support. - Statescan.io - Polkadot & Kusama Blockchain explorer. diff --git a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_1.svg b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_1.svg index cd9e1b4a4..2403cd910 100644 --- a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_1.svg +++ b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_1.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_2.svg b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_2.svg index 2603229b9..669a6974d 100644 --- a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_2.svg +++ b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_3.svg b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_3.svg index 5badb8be9..2652d4d0e 100644 --- a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_3.svg +++ b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/async_backing_3.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/unincluded_segment_1.svg b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/unincluded_segment_1.svg index 63b83f8b0..42cbfb6d5 100644 --- a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/unincluded_segment_1.svg +++ b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/unincluded_segment_1.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/unincluded_segment_2.svg b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/unincluded_segment_2.svg index 960d2e7d7..7907839e8 100644 --- a/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/unincluded_segment_2.svg +++ b/syllabus/7-Polkadot/assets/shallow-dive-asynchronous-backing/unincluded_segment_2.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file