Polkadot Summit: Barcamp - Submit Agenda Topics (30 Nov, 1 Dec)

[Arwen]

How to submit an agenda topic to Polkadot Summit: Barcamp!

Unique-to-Polkadot Innovation

The Summit focuses on unique-to-Polkadot innovation, bringing together Parity Core Developers and other ecosystem developer representatives.

Barcamp

The Polkadot Summit will be organised Barcamp-style. BarCamp is an ad-hoc gathering born from the desire for people to share and learn in an open environment. It is an intense event with discussions, demos, and interaction from attendees. The event doesn’t cost any money, but there is a price: all attendees must give a demo, a session, or help with one.

Agenda

The agenda of this Parachain Summit: Barcamp will be tailored to how we can drive deep collaboration across the Polkadot ecosystem, leveraging the unique capabilities of Substrate, Polkadot, and its parachains. Agenda proposal can be submitted as a comment on this Forum thread. There are 6 break-out rooms available, ranging from 22-44 pax. to 6 pax.

How do I submit an agenda item?

1. Keep the scope in mind: Unique-to-Polkadot innovation. Be mindful of room sizes: Big rooms are for big topics in big groups. Small rooms are for deep topics in targeted groups.
2. Submit your slot proposal on the Forum as a comment on this thread.
3. To be considered, please provide:

• Session Title (e.g. XCMv3 use cases in Defi)
• Who will host the session (e.g. you)
• Team Name (e.g. your project/company)

[colin]

Session Title: Implementing and Testing Mathematical Computations in Substrate
Host: Colin Grove
Team Name: HydraDX

Challenges with fixed-point math and rounding error issues are faced by all blockchain developers, as are the severe consequences of rounding errors in favor of a potential attacker. This session would be a discussion of what tools, processes, and strategies different teams building on Substrate use to efficiently push exploit-free code.

I would start by going through some internal guidelines we at HydraDX are developing on how to write mathematical code and in particular how to write tests, to give the conversation a starting point. But we are not by any means experts and this session is intended to be a conversation in which we can all learn from each other. Although many of the principles involved could be useful for any blockchain development, by focusing on Substrate we can dive deep into very specific details and tools.

Possible topics covered:

• Numerical methods for fixed-point math
• Numerical analysis, rounding error analysis
• Property testing and other testing approaches
• Arbitrary-precision math crates/strategies (like rug) for testing code

[matt]

XCM: What lies beyond the bridge?

Hosted by Matt and David (me and @dawufi) from OAK Network

How can we expand XCM adoption and establish Polkadot as the leader in cross-chain messaging?

Remote execution accomplishes both by enabling parachains to leverage extrinsics and contracts from foreign chains using XCM. Let’s discuss the current state of remote execution and share solutions for combining services from multiple parachains into a single Polkadot experience.

Topics proposed for this session:

0. Use cases - introduction to remote execution and examples of features that leverage services from multiple parachains.
   Note: for the sake of advancing beyond this point, I’d propose we limit discussion to 2-3 cross-chain use cases that are relatively time-insensitive.

1. Security - OAK and partner (to be confirmed) will present and request feedback on our current solution to allow user-permitted remote execution using XCM, the proxy-pallet, and descendOrigin.

2. User experience - an overview of two scenarios to prompt discussion:

• An application (and its users) primarily interacts with a single network and includes XCM instructions to that chain when it seeks to leverage service(s) from another chain (assuming open HRMP channel, etc).
• An application (and its users) switches networks to sign each transaction on its native chain and includes XCM instructions primarily for transferring asset(s) between chains.
  Note: this is only feasible for some use cases and introduces additional complexity to sufficient funding for fees.

3. Fees - Open questions regarding cross-chain transaction fees:

• How can we ensure that the fees are in the right account(s)?
• What currencies would users already have or expect to pay using?
• How can we facilitate liquidity between what users have and what parachains want (their native or a stable)?

[rphmeier]

related: Cross-team Workshops at SubZero

I have a few ideas for sessions:

• runtime composability: asynchronous and synchronous
• blockspace allocation mechanisms. parathreads, short-term leases, future scheduling possibilities
• discussion on an RFC process & the Fellowship

Nothing highly concrete yet

[alexei]

• Coordinating Parachain and Polkadot Bizdev Efforts
• Host: I can host
• Interlay

---

Problem 1: Lack of Tooling and Institutional Support
Polkadot and parachains lack tooling, (hardware) wallet, and institutional support.
The availability of custodians, auditors, fiat on/off-ramps, hardware wallets, market makers, exchanges, as well as support of mainstream wallets with existing user-bases (metamask, etc.) are some of the key points reviewed by product teams when deciding where to launch.

Solana has strong institutional support, Avalanche is EVM based and hence has an advantage, just like most L2s. Cosmos is seeing strong push since the likes of dydx and large exchange-chains (with large existing user-bases!!) decided to use Cosmos SDK for their deployments. We know for a fact from a few institutions that this is why Cosmos is likely to be integrated first.

Polkadot leads in terms of developer activity - however, if these dev teams don’t find the necessary tooling and support being available, they will not find sufficient VC and product-team support to actually deploy on Polkadot. This is already happening.

Another aspect is user behavior: if Ethereum users (this is the largest user group in web3) don’t have to change their habits to use parachains, it will become much easier to onboard them into the ecosystem.

→ Polkadot needs more tooling and institutional integrations.

Problem 2: Lack of Cross-Team Coordination
What has been happening so far: individual parachain teams and Parity have been approaching institutional players individually, without coordination. The result:

• Parachains are told they are too low of a priority by themselves
• Parity is told: “Please show us demand”

We realized that most external teams don’t know that parachains are very similar and close to being “support one, support all”.

Problem 3: EVM vs Substrate-native
Interlay hence launched a first attempt to coordinate a joint custodian business case for Fireblocks - with positive results. However, the deal has still not closed (market played a role) amongst others because most large parachains have EVM support, and hence don’t see substate native integrations as an imminent priority.

While EVM integrations are great and quick to ship - the lack of prioritization for Substate native integrations is slowing down the entire ecosystem.

---

Who should participate?
CEOs and BD/partnership/ecosystem leads

Desired Outcome
Agree on how to better coordinate bizdev efforts between parachains and Parity.

[Vincent]

Session Title: Decentralized Bridges

Hosts: Vincent Geddes, Alistair Singh
Team Name: Snowfork

This will be an informal session to discuss the state of decentralized bridges between Polkadot and other L1s, including Kusama and Ethereum. I would start the session by describing Snowfork’s approach with Snowbridge, and then we can go on to discuss other topics, including those listed below. Other bridge teams are welcome to join and add topics for discussion.

Cross-chain Governance

Light clients don’t solve the problem of decentralized governance. Some governance ability must be in place on both sides of the bridge to keep the light clients working as consensus algorithms evolve. How do these two governance bodies relate to each other, and how can we limit the attack surface?

The Future of BEEFY

While BEEFY makes trustless bridging possible, there is still a significant operational cost. BLS signatures can drive down this cost, though the necessary support still needs to be added to Substrate, Polkadot, and Ethereum. Lets discuss this roadmap.

Defense in depth

Even trust-minimized bridges based on light-client and optimistic technology can and have been exploited, and so an appropriate security posture is required at all steps. What can we learn from other bridge hacks?

Efficient Message Relays

Users want their cross-chain messages delivered fast, cheaply, and trustlessly. Achieving all three goals is hard, and so tradeoffs often have to be made. Messaging endpoints also operate with incomplete information, namely the cost of relaying messages to to the other side.

[pierre.besson]

Session Title: Deploying Polkadot parachain nodes
Session Host: Pierre Besson
Team Name: Parity Devops Team

Proposed session content:

• Demoing Parity’s testnet deployment and management stack.
• Sharing/discussing past experiences with blockchain infrastructure operations
• Discussing existing pain points and future cross team collaboration

[WilliamFreude]

Parachain Emergency Recovery

Hosts: William Freudenberger, Albrecht Weiche
Team Name: KILT

Since the launch of parachains, numerous Dotsama teams required relay governance to unblock their parachain by overwriting the current WASM. It is clear that no project hopes to ever be in that boat but unfortunately humans make errors.

According to the guidelines of the relay Technical Committee, it would not fast track the recovery of an inoperative parachain if it does neither concern relay chain security nor has funds at risk. As a result, a parachain can expect to only recover via the relay’s public referendum queue. In the case of Governance 1.0 and Polkadot we are talking about 8 weeks minimum until the para’s salvation referendum would be executed on the relay chain. It is not unlikely that a project might suffer damage on the scale of extinction before that time.

Of course, Governance 2.0 could theoretically expedite this process. However, the majority of relay users might not care about that specific frozen parachain such that the confirmation period would not be reached in orders of magnitude quicker compared to the current Governance 1.0. Moreover, the Fellowship would not whitelist the referendum either, based on the above assumption.

In the end, every parachain should have the possibility of executing an emergency recovery on the relay chain. The strength of the Polkadot ecosystem lies in the collective of all projects and thus it can be drawn down by a single one as well.

We would like to open a panel discussion about the topic and propose one possible solution which uses XCM for parachains to opt in to the recovery by replicating their Council with a single purpose power on the relay chain.

---

Possible topics covered:

• Recap of current relay Governance 1.0 process to fix halted parachains
• Governance 2.0
• XCM

[sourabhniyogi]

Visualizing XCM Remote Executions + Transfers
Hosts: Sourabh Niyogi + Michael Chung
Team: Polkaholic.io / Colorful Notion

This fall we added the ability to trace Remote Executions (initiated on Moonbase, executing an EVM Tx on another parachain) as well as XCM Transfers to polkaholic.io. We will demo how easy it is to do a XCM remote execution “transactWithSigned” on Moonbase, visualize the operation, and request feedback from parachains + smart contract devs who need improved XCM tools in the coming year.

[skedley]

Session Title: Breaking up identity and security in Substrate

Hosts: Dudley Needham and Raphael Flechtner

Project: KILT Protocol

Cryptographic identity, the key building block in any blockchain system, combines identity and security (authentication). As a consequence, this identity concept does not work well for systems that involve long-lived identities and non-transferable assets.

KILT Protocol is a system where non-transferable credentials are linked to persistent pseudonyms. To cater for KILT’s use case, we have implemented Decentralised Identifiers (DIDs), a ‘fatter’ identity concept that decouples identity and security and can function as an identity hub.

We propose to showcase KILT Protocol’s solution of implementing DID-based authentication in a decentralized consensus system enabled by Substrate’s extensible origin concept. Furthermore, we want to discuss and explore how DID-based identity and authentication can cross inter-chain boundaries to serve the identity needs of the Polkadot ecosystem.

Showcasing our solution would cover the DID pallet, our new DID origin, and examples of how this type of identity is used in KILT. We would also like to discuss the challenges we have faced in integrating a secondary form of identity and authentication to Substrate. Finally, we want to explore ideas for how we can interact with parachains on Polkadot and other ecosystem partners.

[rotemcarmely]

• Session Title How Can DevRel Help You Build a Strong Developer Community
• Who will host the session Jonan
• Team Name Parity’s Developer Relations Team
  In this workshop, we will cover what DevRel is at Polkadot, what our strategy is, and what we can do for you!
  We invite you to share your pain points in regards to growing your developer community (whether recruiting, partnerships, or users, etc.) and we will together brainstorm how to solve those problems by engaging and growing developers in your ecosystem and establishing feedback loops. We’ll also cover how the DevRel team can partner with you in the future to continue to scale said community and leverage the Polkadot network of builders!

[gabe]

• Session Title GitArch demo and the future of Polkadot NFTs
• Who will host the session Me
• Team Name InvArch

In this session I will demonstrate GitArch, InvArch’s censorship-resistant Git hosting solution using DAOs for ownership and management of NFT based code version, and will jump into how a unique application like this can be made without smart contracts or use case specific pallets. If time allows, I would also like to jump into how XCM plays a role into the future of on-chain development and deployment.

[wirednkod]

• Session Title ZombieNet Walkthrough
• Who will host the session Nikolaos Kontakis
• Team Name ZombieNet/Parity Technologies

Integration tests have always complex setups, and blockchains aren’t the exception, lots of moving pieces before even start making assertions. In this workshop we will see ZombieNet, a CLI tool that aims to be an integration testing framework for substrate based networks.

We will walkthrough on different use cases for both spawning and testing ephemeral networks, with a friendly and easy to use configuration and DSL for writing tests. We will also cover real use cases, mixing configurations (relaychain/parchains), CI integrations and common mistakes.

[woss]

Session Title Multi-token community contributions for verified digital creators and Open-Source developers
Who will host the session @digitalillusion and me
Team Name Anagolay Team

---

Imagine if Keybase and Brave had a baby, and that baby grew up to be a platform where digital creators are at the center, they can verify their revenue stream channels and accept support from the community in fiat and crypto.

In this session, we will explain how verification and tipping work and demonstrate the current functionality. We will also talk about why this is needed NOW, why content creators should care, and how Anagolay can help open-source developers to finance their projects.

[jak-pan]

• Session Title Ecosystem security: Protection against toxic flows and alerting
• Who will host the session me + @mrq
• Team Name GalacticCouncil | HydraDX | Basilisk

We have seen a couple of hacks in the ecosystem already. I would like to discuss a monitoring system and ways we can limit flows of toxic assets if catastrophic event happens at either XCM level or by parachains themselves.

[jak-pan]

• Session Title Substrate development experience improvements
• Who will host the session me + looking for help
• Team Name GalacticCouncil | HydraDX | Basilisk

I would like to continue on my sub0 talk and discussions on the last parachain summit with actionables and quick wins. How can we improve lives of substrate devs now? Everything from tooling through scripts and automation to best practices. I would like to make this more involved and maybe hack some things together in groups. Please bring the best hacks or tools you use with you.

[jak-pan]

I would also be very interested to attend this Cross-team Workshops at SubZero - #7 by rphmeier but proposed 2 already so won’t push it. Or if there is more interest could help with it rather than one of the two above.

EDIT: Or we could in theory merge this with my second proposed one since they are UX related?

[timdobie]

Session Title - The Polkadot Blockchain Academy

How to contribute to and benefit from the Academy.

The second edition of the Polkadot Blockchain Academy is taking place in Buenos Aires in January 2023, there are lots of ways to contribute and benefit from the Academy;

Send team members

Sponsor places or events at the Academy

Hire new team members

Give a guest lecture

Give a speech

There are costs involved, this Academy is ecosystem wide, to be contributed to by you, to be benefitted from by you.

This is a session to discuss these options in more detail or to suggest other ways to benefit or contribute. The aim here is for Academy team members to share info, answer questions and to generate awareness.

[Fahrrader]

• Session Title Multiblock Storage Migration
• Who will host the session Farhad Hakimov, Greg Zaitsev
• Team Name Unique Network

Storage migrations can be costly. Due to the rigid limitations of the size of the proof of validity for the Polkadot relays, the time needed for a migration is limited – and if a parachain runs out of those precious bytes, with the current systems, it will hang, trying to execute the same migration over and over again, dead in the water.

During this session, we will showcase a possible solution to this limitation, the multi-block storage migration, where a possibly expensive migration can be split and executed over multiple blocks.

If your parachain has a lot of data that might need a restructuring, join us!

[Gautham]

Title: Polkadex Orderbook Demonstration and Parachain Usecases

In this session, We will demonstrate how Polkadex parachain enables other parachain users to place orders directly. Also how users can delegate their assets to external trading firms without giving them custody and an an overview of the security model of Polkadex.

Presenter: Gautham J

Team: Polkadex