Polkadot's Vision - Ubiquitous Computer, Core Time, Accords and Resilience

[filippoweb3]

No description provided.

[laboon]

We should also mention accords as part of this PR @filippoweb3

https://polkadot.network/blog/polkadot-decoded-presents-powerful-vision-across-the-ecosystem-in-two-action-packed-days

[filippoweb3]

@shawntabrizi I implemented your feedback, removed all the parts that contain too much detail, changed the title of the page, removed polkadot representation of the "cookie" with the accords (I am working on it separately). let me know if I satisfied your feedback. Cheers!

[KiChjang]

Overall, I feel like the article is explaining the mechanics of Agile Coretime; while I agree it's important, it's currently deficient in the aspect of "why does this matter to me?"

One of the big things that we didn't talk about is how we're moving away from the slot auction model -- this really needs to be highlighted, as I've talked with teams in person before, and they're absolutely hyped about the ease of use and flexibility that the coretime marketplace is going to bring. We should also then explain how one can acquire coretime easily under this new conception of Polkadot.

[filippoweb3]

Thanks for the feedback @KiChjang! Answering your questions:

• There is a section about switching from slot auctions to coretime sales on the page. Is that not enough? I can add a paragraph about bulk and instantaneous sales, but after @shawntabrizi feedback I removed those details completely and focused on the main changes. I probably removed too much!?
• Why does switching from auction to coretime sales matter to me? I am planning to link this page to the async backing page PR Reorg Async Backing #5176 and explain how in periods of high/low demand parachains can adjust their coretime / core allocation "profile" to get parablocks ancetstors in the unincluded segments being backed and included at different speeds. I see the coretime narrative as an elegant solution that is tightly bound to async backing and the fact that in periods of:
  • low demand parablock generation time (12s, 18s, more? to fill up blockspace) >> backing + inclusion (6s) -> unincluded segment shrinks -> share a core to increase backing time -> pay less
  • high demand parablock generation time (below 6s) << backing + inclusion (6s) -> unincluded segment grows -> more cores / coretime to lower backing times -> pay more

Let me know if the above makes sense and if there is anything else you suggest to add.

[KiChjang]

• Why does switching from auction to coretime sales matter to me?

Previously, securing a parachain slot required a massive amount of upfront capital to win the auction. With agile coretime, there's no need for such an auction anymore; teams can either purchase some Instantaneous Coretime, or reserve Bulk Coretime as required, and it greatly decreases the barrier-to-entry for software tinkerers and parachain teams.

In accordance to what Shawn mentioned, we don't need to mention specific details on the mechanism of coretime purchase; the core of the message is that it lowers the barrier-to-entry for prospective builders. This is literally the most important aspect when it comes to building on Polkadot. Hence from this perspective, async backing is interesting, but they're again intricate details and doesn't speak directly to what teams care about the most.

[filippoweb3]

@KiChjang I added a summary that highlights the main points of the future direction, mentioned again the bulk and instantaneous coretime rental, and reorganized some text.

[shawntabrizi]

I haven't had a chance to re-review the changes here. The feedback from @KiChjang generally looks good, but I didnt agree with:

Just to reiterate what we've discussed in the Marcomms channel: we should avoid any public mentions of "Polkadot 2.0" and instead always specifically talk about the name of the feature that we want to explain.

Dunno the deeper conversations here, but Polkadot 2.0 is just such a simple brand and idea to capture all of these things, I think it would be a shame if we didnt use it. Even it we clarified that is it likely versioning of the internal software. Just as we have a Polakdot version 1.0 now, these features will be included in a future Polkadot 2.0 version (or sooner).

[filippoweb3]

@shawntabrizi @KiChjang, after Bill's reply and reading the Marcomm element chat, I think it would be best to leave the current title until there is clear guidance from the marketing team.

I am still keen on adding a proper diagram to explain the core / application narrative. This can be added as a separate PR if you agree. Let me know if the current version of the page looks better and can be merged.

[shawntabrizi]

Overall, I still find the page a little funky.

The narrative voice is strange, since it uses first person we sometimes, and then switches to third person in later parts, and the presentation of the content / topics is not to me fluid.

Ultimately, I think these are just some of the challenges of converting a talk to a document.

That being said, I dont think there is much wrong or inaccurate with the content on the page, and thus funkiness aside, someone who reads it will probably be able to learn many of the new thoughts happening in the space.

I am not against merging this, which may help move forward to building an even better version of this content and data.