I’m in the midst of drafting slides for a future lecture covering availability cores in Polkadot. Cores are an important abstraction for creating a flexible market for blockspace, the product of Polkadot. But in attempting to speak about blockspace I ran into trouble with terminology. There doesn’t seem to be a concise and accurate term for an indivisible unit of blockspace in Polkadot.
Here’s some necessary context for this discussion:
Blockspace is the capacity of a blockchain to finalize and commit operations.
Polkadot blockspace is consumed in two ways:
When the relay chain validates, includes, and finalizes a parachain block
When the capacity to validate a parachain block is left unused and expires
My first intuition is to use the term “parachain block” to refer to Polkadot blockspace units, since there is no smaller unit of operations that can make use of Polkadot scaling. But this term doesn’t fit very well into sentences about unused blockspace imo. This leaves me using the unwieldily phrasing “unit of blockspace” for the time being.
Some ideas:
Parachain block (The intuitive unit)
Core-block (The capacity of one availability core during one block’s time)
PPB (Potential Parachain Block)
Ideally the chosen term would naturally fit into the sentences:
“I bought a ___ of blockspace”
“The ___ expired unused”
@rphmeier You seem best equipped to get this right, if you haven’t already.
I don’t think my answer is a catchy one or particularly helps with building narratives, but in Substrate terms, the technology upon which Polkadot and its blockspace is built, the underlying capacity of blockspace is in fact Weight.
In practical terms, blockspace is either block-length getting filled or block-weight getting filled.
From a parachain perspective, the limiting factor is usually the PoV dimension of Weight.
I like weight as a unit of blockspace, though I agree it isn’t particularly catchy. Mainly I like the way it would let businesses speak about flows of blockspace in absolute terms. The amount of usable blockspace in a parachain block changes over time (asyc backing), making it a potentially faulty unit.
Weight reminds me a bit of freight tonnage or oil pipe flows.
Now it occurs to me that STPS (standardized transactions per second) as measured by weight might be a good choice. The industry is already familiar with the term, and it ought to prove a more consistent unit than parachain blocks.
To adopt STPS completely would involve exposing that terminology to the consumer, perhaps instead of the notion of leasing a parachain.
“We purchased a two year lease of 20,000 STPS realized on a 6 second basis”.
It sounds like STPS can’t be defined differently across relaychains - but it be nice to be sure.
IIUC, ‘potential block’ is not suited to fostering cross relaychain competition - so scrap that.
Don’t use STPS. For one, I’m not sure it’s actually that much of a standard. But most importantly, using TPS communicates the opposite of what is generally meant by blockspace: flexibility. In the long run, I think we want to move towards metrics where parachains can beat general purpose smart contract platforms. Maybe something like minting NFTs on a parachain that can do that natively. I expect the more throughput-focused chains will start using metrics beyond just native transactions in the near future as well.
@kianenigma has a point if you want to be precise, which may be appropriate for this lecture. For general marketing, though, I would just use “block” so we’re not relying on ecosystem-specific terms or inventing new ones.
My intuition is there is a few dimensions to measuring blockspace:
Flexibility
Security
Throughput
Throughput is certainly measured by Weight in the Polkadot ecosystem, however Weight leaves out these other dimensions.
For example, if another chain shows they can actually process much more weight per block, but they did so at the cost of limited flexibility and security, then we wouldn’t really be doing justice by comparing these two protocols by Weight throughput alone.
Generally, I think trying to invent a single word to describe the whole notion of blockspace is probably oversimplifying, and likely causes more harm than good to understanding what is actually being represented.
I DO believe STPS measurements across ecosystems might be the closest we can come to comparing apples to oranges of protocols. On top of how many Standard Balance Transfers can be performed on a chain, we must also look into how much it might cost for someone to attack / revert one or more of those transfers.
This suggests that “standardized transactions per validator term” should be used as the txn throughput proxy to divide d by (@OliverTY thoughts?).
I hesitate to use other parameters (epoch, session, era) because that runs the risk of making this appear Substrate specific, and it would be great if we could land on something that could reasonably be calculated for other protocols, and not just other Substrate relaychains - fostering competition more widely than just Substrate.
Thanks. That seems a reasonable starting point. The economic dimension could reasonably be approximated by d=a x b x c:
a: the stake of the marginal (last admitted) validator in USD (time varying)
b: the number of validators required to influence/control consesus/block-finalization (time varying)
c: the number of ‘block-ticks’ (or slots that produced a block, as a noisy metric of time) during the “validator term”
It would be useful to know sTPS/d or d/sTPS as a first pass ranking of different relaychain blockspace costs.
The audience is developers and BAs so we can assume some prudence in using such metrics to compare relaychains.
“Polkadot 8.4 d/stps cost USD 3.50"
“Polkadash 7.1 d/stps cost USD 4.00"
“So, obviously, we prefer Polkadot - it’s notionally more expensive to control consensus there, and it costs less.”
It does have the disadvantage of being specific to PoS networks. However, other protocols should be able to come up with a comparable metric that improves on a shoulder shrug when someone asks about the cost of blockspace relative to another protocol/relaychain.
More importantly, promoting a metric, whatever it ends up being, does incentivize the collection, publication and scrutiny of the constituent parts.
Maybe not, once there is a common (even if intuitive) understanding of what that single word means - here it will help you to think through various proposals by bearing in mind the two single words “speed” and “acceleration”.
The single word, speed, is commonly understood to summarize two dimensions: distance and time, m/s.
The single word, acceleration, is commonly understood to summarize two dimensions: speed and time, m/(s^2)
Others may argue acceleration summarizes a different aspect of two dimensions summarized by speed: distance and time, m/(s^2)
Anyway, I’d be optimistic the audience for such a metric will be able to wrap their minds around this - whatever it ends up being.
If we accept a metric definition that encompassed more than one dimension, then we are essentially describing the block production capability of a protocol (or Substrate relaychain configuration).
What capabilities are described are defined by the metric. So far we have throughput (standardized transactions over some interval) and capital-at-risk. When we have a definition of some other capability we can probably include that, think in terms of momentum: kg m s^(−1)
Standardize block-capabilty (block-capability or blockcab - blockcap sounds like a ceiling/limit)
“We purchased a two year lease with a blockcab of 8.4 usd/txns for avg/est cost USD 3.50 per block”.
“I bought 100 blocks with a blockcab of 8.4 usd/txns"
“The block-capability expired unused”
“On Polkadot, the blockcab is 8.4 usd/txns, with an avg/est cost USD 3.50 per block"
“On Ethereum, the blockcab is 7.1 usd/txns with an avg/est cost USD 4.00 per block"
“So, obviously, we prefer Polkadot - it’s notionally more expensive to control consensus there, and it costs less.”