Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
PBA Special: JAM with the Builders
Recorded: April 9, 2025 Duration: 1:34:54Space Recording
Short Summary
The Polkadot Blockchain Academy's live stream delves into the innovative Jam project, showcasing diverse implementations, strategic partnerships, and the community's growth mindset. With upcoming events and financial incentives like the Jam Prize, the ecosystem is poised for significant advancements in decentralized technology.
Full Transcription
And welcome back to another live stream here at the Polkadot Blockchain Academy in Lucerne.
We have a wonderful audience with us today.
And we've arrived at the part of the academy where we dive deep on Jam.
We have a wonderful panel with us today.
We're going to throw it over to Kian Paimani to introduce the panel and get going.
Enjoy.
All right.
Thanks, everyone.
For those who are watching us in the classroom, most of the people in the panel, you know them.
But for the live audience, let's start with a round of everyone introducing themselves,
telling which team they're part of, and how they got into Jam.
So I'll hand it over to Tomek for the first.
And what about you? Oh, you're last. Okay.
Also, I have a teammate to represent my team.
Hello everyone, my name is Tomek. I'm part of the company called Fluffy Labs and we've decided
around eight months ago to implement Jam in TypeScript, and the implementation is called TypeBerry.
Along the way, one of our goals was also to improve the development experience of other Jam teams,
so we are also focused on building Jam-related tooling.
Can you ask yourself why Fluffy Labs?
Why Fluffy Labs?
Oh, why Fluffy Labs? Why Fluffy Labs?
I was trying to come up with some name that is kind of funny because
everyone was coming up with names that are super serious,
like these mathematical structures kind of labs and something else.
Formal specified.
Fluffy Labs can also be like Fluffy Labrador.
This is why on our sticker we just have a dog.
So that's the idea.
It was supposed to be fine.
I'm Daniel.
I'm part of the Jamixir team, building Jam in Elixir,
the programming language, functional programming language.
The team is just me and Luke, two people. I started to implement Jam like one year ago,
just after PBA. I am a PBA alumni in Hong Kong and I also sometimes to learn more about Jam
because I'm learning while I'm doing, I stop? No? Can I do it? Everything
is right? Okay. I also share some content about Jam on Twitter so people can also
understand what we're doing and we know that it's a long way until Jam is
working on production and then services being built on top of it so it's a long way until Jam is working on production and then services
being built on top of it so it's a really fun time for me. I'm Maciej, I'm
part of the Grey Matter team and we're also building an Elixir based Jam
implementation but in our case team is a bit larger. We have four members, but all of us
are working part-time. So like the main outtake you want to have, you don't need to dedicate all
your life to Jam. There can still be teams building on Jam or building the Jam itself,
even as a part-time thing, hobby, maybe you can do just a light client on it. There is a lot of
tooling, a lot of stuff that can be done for all the different types of people it's not just for people that
can throw away their lives and maybe do something it's for a lot of different
there's a lot of different options in that space and and we I think at this
point can as a team that all is working part-time accepted that we will probably
not be the fastest but we want to get as far as we can and do as much as we can and collaborate with
other teams in the ecosystem, sharing the tools, sharing the testing sets and
everything to make the protocol more resilient. And for me personally, I
started working on Jam because I believe, and I think many people share this
believe, that this will be the future of Polkadot. I think it will provide further abstractions, stuff we can build,
and open many different avenues that were not possible before.
Hi, I'm Alistair, lead scientist at the Web3 Foundation,
and I'm mostly just giving theory support for the design of Jam.
All right, thanks everyone.
And for those of you who don't know, I'm Kian.
I'm also part of Grey Matter.
And as mentioned, working part time on Jam.
My main motivation in doing so is also
to gain knowledge of the protocol, especially
in the first two milestones of the price,
such that I can keep myself up to date
and have further avenues of contribution in the future
when Jam is actually in production.
Okay, let's now ask everyone to tell...
I mean, some of you covered how you came to Jam
and what was the story.
You can elaborate a bit more on that.
Say what is your motivation
and why you choose this endeavor to...
Go into more detail of why you chose this endeavor,
what's the motivation, what excites you. So for me and my team, initially I had this idea to
work on this part-time as well, just like because I found this really interesting. I used to work at Parity.
I worked on Polkadot in the past.
Then I had a short break, and then I was like, OK,
that might be a good way to come back to the ecosystem
with all the knowledge, baggage that I gathered over the years.
But I shared this idea with a bunch of friends,
and they got pretty excited as well.
And this is why we decided to end a little bit more kind of full time on this.
And yeah, I guess that's it.
Yeah, you can make it just to change the order.
So in my case, I think me and Kian being in the same team
is also partially because we align with the same idea
of why we are there.
I also want to learn about the protocol
because I think it will be important in the future.
And even though I have other stuff I do in my main job,
I know that this will be relevant eventually.
I have a bunch of people, either PBA students
or in other places, asking me about Jam.
And I feel like I need to have the answers to those people as someone that is working on the current Polkadot protocol.
And there is no better way than actually trying my hands and building it and learning about it,
how it works, going through the gray paper and all the different stuff in it.
I think this is like the main reason why.
And the other is I can do all of that because I
believe that this protocol if we can build it will provide new things that
were not possible before if I didn't think that then I wouldn't think there
is a reason to learn about it if there would be no hope in this stuff and I
think there is a lot of hope and extra exciting features it can enable
for exciting features it can enable.
Alistair, do you also want to comment on maybe what do you
find interesting about Jam?
That's a different question than you're asking.
Why are you here?
I mean, I came here because I was consulted about some of Jam.
What do I find interesting?
Well, the data availability thing is going to be fun.
I can't wait to see how people are going to use that.
What else?
I mean, so if you ask me the question, what is Jam 4?
I would think that aside from the generalization of what's going on in Polkadot,
actually we got to the point where Polkadot wasn't comprehensible to one person anymore.
And part of the motivation behind the gray paper was just,
let's try and have a single protocol that we can spec for at least part of Polkadot.
And if we can understand it, then it's going to be maybe easier to optimize.
And as a result, Jam is aiming for a much higher performance than we can get out of Polkadot today.
It's an ambitious protocol.
And, yeah, I look forward to seeing it.
Okay.
Sorry, I wanted to add something.
Purely from the engineering point of view,
if you look at the project, at the jump project,
it's like you have a complete specification of the protocol.
It's still evolving, sure, but it's meant to be complete.
And you have a completely greenfield project.
You can pick whatever language you want
because they are split into many language sets.
And you will eventually, you can also take part
in the Jam Prize contest, let's call it,
and be rewarded for that.
So I think from that point of view,
it might be attractive even if the philosophical kind of
things you are not fully aligned with yet, I would say.
Yeah, when I started to think about,
so I came to PBA with the idea I
Came out of PBA after doing PBA. I knew that I wanted to build something on top of
On polka dot something related with polka dot, but I didn't know exactly what and then Jim came
Right after I finished my PBA course, so it was kind of like obvious thing to do,
even better with the prize.
So I'm not working for the prize.
I think the prize is the secondary gain
from working with Jam, because even if we don't finish
and if we don't get the prize,
we will get so much knowledge and so much connections
and working with guys, with the best guys like you and all the other Jam implementers
is something so valuable. Working close to Gav and building this thing together is so much
valuable because after it, there will be a lot of things to build on top of Jam.
Services, services on top of services,
and knowing how it works under the hood,
it will be a very great differential between us
and the people that come later.
So this will be very valuable.
And I'm building Jam because I strongly believe in the web3 vision
the core vision written by Gav
Like five years ago, maybe maybe ten years ago
Which is we want we need to provide a system that is
Permissionless that is decentralized and that is resilient to attacks.
And up until now, there is no system like this.
We can call Ethereum, we can call any other blockchain that is out there,
but none of these are capable of running global systems
and having everybody using as a core technology.
And Jam, I think, is the first time in history, even if we have Polkadot, but Jam is the next level, which
will actually allow the world to use blockchain in their daily lives. So I
strongly believe in this vision and I couldn't help but like let's build it because we are pioneers and I like to be here
with you. Yeah amazing also now that we've heard from the background of everyone I think it's
noteworthy to say we have a very good mix and I can say as an observer of this group of people
I'm actually very happy that we have both let let's say, Polkadot veterans that have been here since when 20,
I mean, from the beginning, but we were working on Ethereum
even before Parity and, you know, Parity was working.
Like, this man was building Ethereum before Polkadot.
So that's very good to see.
And we have two of you who are actually
from the very same program that we are here.
So I hope this also inspires the audience here that you know it's not an insurmountable
task. You know people who were in your position a year ago and three years ago
or two or three years ago are now you know implementing this protocol and it's
something that's available. And I would say that we are still early because this
like it's for me at least is a long-term journey it's not a
like 100 meters uh race it's a marathon and we are just in the first kilometer of like 42 so
there are still a lot of uh roads to to run and everybody is still very welcome to join the boat for, at least in the next five years, it's still early,
in my opinion.
Yeah, definitely don't hesitate to join in
because you think it's too late.
It's not too late.
There is still so much work to be done.
Yeah, well said.
Daniel, you talked about some of the other teams
and the community aspect of Jam.
Maybe one of you can elaborate more on what this community vibe in Jam is right now.
What are the benefits that we can foresee with having this group of people that are completely unrelated to one another actually work on Jam?
And give your experience generally working with the other teams. Yeah actually this this is one of the I think it's kind of genius the way the
prize was put because incentivizing different people from anywhere to work
on the same thing and having a blueprint which is the gray paper as a guide so
it's everybody following this guide independently. And if everybody works
correctly as written, in the end, we will be able to synchronize ourselves into a single network.
And we started to see this happening like a few months ago when teams started to produce blocks
in their own implementation and send these binaries
to other teams to import and check if the blocks are correct.
And nobody knew anything about any line of, nobody saw any line of code from other teams.
And as we started to send blocks to each other, and we say, oh, this is working, this is working,
oh, this is not working. So probably there's a bug here, there's a bug there, let's try to
figure out, each one trying to figure out its own bug. So I think the community
started to evolve from this and now we are meeting, we have a meeting in Lisbon,
everybody is welcome in May, we're gonna have our Jam Experience event and we're going to have our Jam Experience event. And we're going to try to launch the test net by then.
Let's see if it's possible or not.
But yeah, we are working hard to make at least a few
implementations test ready for the Jam Toaster.
And coincidentally, the Jam Toaster,
which is a data center that is being
built to run the test net or the pre-test net, let's say.
Because all the blockchains that we see out there don't have this infrastructure with a lot of computing power to run real-world scenarios in the blockchain.
in the blockchain and we have at our disposal like a
Hundred I know I don't even know how many cores and memory like
petabytes of
disks and
Terabytes of RAM to to run the project and each team running its own implementation and talking to each other
Implementation and talking to each other, it will be huge.
It will be huge
Also, for those of you who don't know,
I think there's already 38 teams that publicly declared
that they are implementing Jam across, I think,
I don't know, probably like 15 different languages.
And also, you might be thinking, OK, so what's the actual goal?
Why do we need 15 implementations of Jam, actually?
And I feel that the actual goal is not necessarily
to have all of these 15 implementations
be running in production, equally distributed
across the network, but rather to build up
this community of experts, kind of like a next generation
of the technical fellowship that we have in Polkadot right now
for Jam, but actually do it beforehand,
even before we have a running network,
and we will be ready to evolve later.
Yeah, for sure.
Like the main, I think, idea behind the prize is to try and as much as you can
decentralize the expertise in the community, spread the knowledge as much as possible.
This is already something that's being worked on with the PBA.
PBA tries to spread the knowledge and PBA, JumpRise and the fellowship
are all attempts to try and spread the knowledge as much as possible and make it as accessible as
possible to different people. So different people can participate in the protocol, can know it,
can actually build tools on it and then can advocate maybe either for the protocol or try
and help other teams build applications on top of the protocol and understand how to actually do it and we need to have more and more
of that instead of centralizing the expertise and I think it's crucial for
the future success of the whole ecosystem yeah I can allude to a point
that I had in my lecture this morning that one of the points of the polka dot
fellowship right now is to hedge against any particular company
being the development bottleneck or the knowledge bottleneck of the existing Polkadot.
And Jam with this prize and like this 40-something theme and how many people is in there?
Maybe like 100 or something right now is already like five steps ahead of that because you know Jam is not Jam's knowledge expertise and development and maintenance in the
future is completely decoupled from any organization or any company I think
that's pretty fantastic okay let's say let's talk about the future a little bit where each implementer team
wishes to see Jam and their clients in the short and midterm like within the
next one year what do you want to achieve and see both in your team and
Jam in general so let me start from Jam I really hope that within a year we will have a running testnet of
Jam and I really think this is achievable. And for my team, well, we didn't pick the fastest
language to implement Jam in, so it might be quite hard for us to go beyond milestone 3, which is Kusama-level
performance. However, since recently there are different paths that we might take that,
for instance, don't require us to implement, in our language of choice, to implement the
high-performance PVM recompiler to the native code, because most
likely that would be the kind of prohibiting factor for us. So yeah, we have ambitions
to go kind of beyond milestone two, but I would be happy if we reach milestone two and
then, for instance, pivot into being in-browser lite client for Jam.
into being a in-browser lite client for Jam.
Yeah, for us, Elixir, it's still a question mark
if we can make it up until milestone five.
I'm a believer, but let's see how it goes.
And there's always this alternative path
of using
binds with Rust or other lower level languages
for the bottleneck things.
And I strongly believe that Elixir is a good language
for managing and coordinating the upper level stuff.
So probably this will be the path.
If we can't make it high performance in the lower levels,
at least we will keep Elixir as a very strong and mature
and bugless node for the upper level stuff.
And my plan is to stay within Jam for the next at least 10
years, because there's a lot of work to do.
After finishing Jam, start building services on top of it and helping others to build on top of it.
It's a whole new world.
So, as I said, it's the beginning.
And I'm very, very happy the way we work together, because
at the same time, I have the amount of independence to work the way I want.
I don't have a company, I don't have a boss, I don't have a customer.
So basically, I'm part of a community, and working in a community I think is the best,
and this community is awesome.
We've been sharing with each other very friendly,
and I hope that this will continue because these are the people.
And yeah, so I'll be working and trying to share as much as I can with other people.
This is what I love to do.
And I think it won't stop.
Yeah, from my side, definitely echoing some of the concerns and hopes about Elixir.
I fully share them.
But what I can add from my side is I started working on Jam very, very recently.
I mean, barely a month ago.
So I'm still in the onboarding process
to all of that stuff. It can be daunting at first. I'm slowly walking through all of that knowledge
and trying to process it. And I am hoping, because I noticed that many of the teams that are working
on Jam right now, they're still on the early stages of the implementation. They're working on milestone
one, working on the state transition function of the simple, still quite monolithic aspects of Polkadot. And I know that
many of them will soon be transitioning to working on the more sharding aspects of Polkadot, how we
can get all those different services, all those different cores to cooperate together. And this
aspect of Polkadot is something I've been working
all my time in Polkadot, in Polkadot 2.0,
and I'm hoping to transfer this knowledge to Jam,
help all the other teams, not necessarily just mine,
but hopefully a lot of mine primarily,
and then we can distribute the knowledge and resources
to all the other people about how we can do elves,
how we can do sharding, how it should
operate in Polkadot. And I'm hoping that within a year, we can actually start working on elves
in Jam and get some actual results. Because this is something my team and party has been working
on for years. And we need to pass on some of that knowledge and expertise that we've built on it and all the optimizations we implemented into it.
Yeah.
Hoping for that, for sure.
From my point of view, it's more a question of what features can we get into version of Jam
and what won't make it.
I mean, so Tenda, right, talked about DKGs
the week before last, right?
If we get threshold crypto into Jam,
we can save the amount of work validators have to do in ELLs by 40%.
We can have 40% lower spec for validators, 40% more cores-ish,
something like that, like a big number.
But I don't know if that will make version one.
And probably you guys don't want it to make version one,
because you'll have to do extra work.
I have a follow up actually for you, Alistair.
You mentioned version one.
Can you explain a bit about Jam's upgrade path in the future?
Because I think it's one of the points of confusion
that at first glance, Polkadot is known for this like forkless upgrade system,
whereas Jam is a chain without a lot of upgradability mechanisms into it.
So why is that?
And then if there are going to be major revisions of the gray paper and a new complete version of Jam,
which would have to be enacted as a hard fork, what could that be for?
Well, already with Polkadot, it's only the runtime that we vote on, right?
Other parts of the client are not part of governance,
so they're basically hard forks.
And this gives you a problem if, for instance,
you want to change consensus algorithm or something.
That's very much, that's still a hard fork on Polkadot
like it would be on Bitcoin.
It's not any different.
So, but yes, Jam will have,
Jam's hard forks will be new,
a little bit new in the Polkadot area.
And yes, I don't know how it's going to work.
The fellowship will be more involved.
They're already pretty involved in
PokerDot runtime upgrades.
But Jam will have its own,
maybe own version of the fellowship,
its own fork of the fellowship.
So yeah, we'll see.
Yeah.
It hasn't happened yet. I've heard one comment from Gavin in an interview that one of the candidates for like the jam fork, so a major new version, would be like quantum resistant crypto.
Maybe I think you're a good expert to talk about that, if it's a thing or I have not misheard it.
I don't know.
I'm still thinking that there's no real urgency with quantum resistant crypto.
But perhaps the important thing is not that we adopt it, but that we have a fork ready to go.
So we're looking at right now all the primitives in Polkadot and seeing what we can make post-quantum.
In some cases, it's easy.
We just switch out our elliptic curve signatures
with lattice signatures, now already standardized.
There's some options, but it's pretty clear what you do.
For other things, like the VRFs we're
using in elves and Sassafras,
it's not so obvious that we can do this with post-quantum crypto at all.
Maybe we should switch to randomness beacons and things like I was talking about this DKG.
We'd have a different DKG for post-quantum.
And we're trying to think about these particles.
And whether we should deploy them on something
like Kusama first.
Yeah, I think that it would be a cost of performance to,
and Jam is doing very well for performance,
to actually deploy an entirely post-quantum system.
But it's important that we have a fork ready to go,
and that probably would mean
all the implementers
figuring out how to
get these various post-quantum things working,
even if we don't deploy it live.
So there is no free launch.
If we want to go
quantum-resistant, probably we'll have to
decrease performance.
It will cost us a temp.
There is no way to make performance and quantum resistant at the same time.
There are some protocols you can switch out with things that are actually fast.
Okay, so it's like you want to be more relying on protocols that just use hashes,
and those protocols are already fast,
but maybe there's a bandwidth trade-off.
And the bandwidth becomes interesting.
Like if I have to do 100 kilobytes snark for my ring VRF
that I used to put on the jam chain,
maybe that should move to a service.
We do sass for us partly on a service and things like that,
but it wouldn't be slower.
The main slower things, things like signatures,
get slower and bigger.
Well, actually, no, they mostly just get bigger.
And the bigger is the bigger problem, actually, I think,
bandwidth rather than performance.
You know, lock space, bandwidth, everything, rather than performance.
So I think it's also worth noting that
Jam is an extremely minimal protocol.
I mean, it doesn't have a notion of a token.
It doesn't have a notion of governance.
It's everything there needs to be implemented as services.
So if we are talking about forking and upgrading the chain,
it's going to be mostly like this major protocol upgrades that Alistair mentioned,
like changing the cryptography to be quantum resistance
or just improving the cryptography for the validators to have less work to do.
But I think there's going to be a very good and simple metric
that can prove that this hard fork or soft fork is actually
non contagious contagious and it just improves the performance or it makes the
the entire system more resilient so there's not I don't expect there's going
to be a lot of contention regarding oh yeah this feature is not something that
we want because it's it's the community split about it the likelihood of an upgrade in jam which requires a hard fork is extremely minimal exactly for this
reason mentioned um to whoever from the panelists wants to address this how would the upgrade path
for the existing polka dot system and parachains would look like on based on your prediction and
understanding right now and we are not there yet
But what do you think will be the path for the existing power chain teams?
I have the question to you to you know
I I would say that I have no idea. Yeah, I have no idea
I'm just building gem you take care of all the rest.
You and all the guys that are watching us because it's too much.
But I know there are a lot of things being worked on. I think there are two parts in this question.
First of all, what is pretty much certain at this point, I want to make it clear,
parachains will have a place in Jam.
This is important. I want to emphasize it every single time I'm talking about Jam. There is a place for parachains will have a place in jam just this is important i want to emphasize it every
single time i'm talking about jam there is a place for parachains and current teams
they will be there will be a way to migrate individual parachains to a service that handles
parachains on jam and then the question is how do we actually do it and this is a more difficult
topic there have been some discussions about the potential regenesis. Is it necessary?
I am also not at the point where I can say yes or no.
I think a lot of people are playing with the idea and trying to figure out what the trade-offs
are.
And it will definitely be up, like fellowship will be involved, maybe governments will be
involved.
At this point, it's hard to say.
Yeah, so the first plan, right, is we build a core chain service
that's capable of running parachains on Jam
and you build the Clayton stuff that they can,
and existing nodes running probably Cumulus as it is
with your parachain built on frame,
will just be able to work.
Well, have the code so that's just able to work.
Then, yes, how do we migrate?
That's a different and somewhat fun question.
But the first thing is to make the logic make sense.
Yeah, I can also build a little bit on Maciej's question
that the aim for fellowship, parity and other teams involved
is to make that transition seamless
but as we have seen, it's a stage of the process
that we have not gotten to yet.
So the exact how of it we will see
but the aim is for it to be a seamless transition
as much as possible. On the maybe slight comment on that as well
even right now we are in poker 2.0 we are currently having a big migration from
the relay chain to services so there is a lot of expertise of how do we migrate
all of this stuff outside and I think during that we might also gain some
extra knowledge into how
even make the jump transition happen and maybe it will shed some light here and
there. Yeah worth noting like a lot of the upgrades that are coming to Polkadot
in rest of this year are moving a lot of things out of the relay chain into one
of the system chains called Asset Hub such that we are not only improving a
few other aspects
of the protocol and user experience
and developer experience in general,
but also it's a preparation for Jam.
So we're already trying to, you know, little by little
move things out of the relay chain
so it's as empty as possible so it can be replaced
by Jam in an easy way.
OK, looking at the time, I have one last question,
which is more like an open one,
and then we can hand it over to the audience to also ask this question.
So, to all of you, any leftover points or thoughts on Jam that you want to share?
Just go over that now.
Anything that excites you, what you want to see in the long term?
Yeah, open question.
Too open to start.
So again, maybe from my purely engineering perspective,
like it's a really unique opportunity right now
when we know that,
kind of echoing what guys were talking earlier,
we know that Jam is strictly more general than what we have in Polkadot right now.
That general that we can take the existing Polkadot system
and kind of migrate the parachains and they're still going to be working.
But the question is like, what else is possible?
Like beyond just taking the parachains and what other options
this new system enables us to do.
For instance, do we still have to have chains?
Can we think of different ways what kind of services can be built on top of Jam?
And what's more, we don't even have a framework to build these services in.
Obviously, there is a kind of experimental framework
that's coming from the parity team and Gavin, the Jam SDK.
But, well, it's running PVM.
You are free to implement your own framework that just compiles to PVM,
which means you can use any of the languages that just compiles to PVM, which means
you can use any of the languages that actually
compiles to RISC-V, which is pretty much any of the languages,
and build a framework that's going
to be a basis for the future applications that
will be running on Jam.
Well, my take is something more philosophical.
Well, my take is something more philosophical.
If we really believe in the Web3 ideals
of making something that is decentralized,
censorship resistant,
and a chain that runs on itself
without depending on any centralized entity,
we are here and we can see that Jam and Polkadot is the only option.
Because if you look around, if you look to Ethereum, for example,
you see that Ethereum is stuck.
The tech is outdated.
The community can't upgrade it anymore.
And if you look at other chains that are trying to reach out Ethereum,
they are all companies centralized with a single token, two or three entities controlling everything.
So all of them are just different projects trying to catch up, but all of them have the
same characteristic. Everything is centralized. Even Ethereum layer 2s, you say, oh, you have a lot of liquidity on base or on Arbitron or whatever.
Everything is centralized.
So it's not Web3.
If you want to build something that is really Web3,
I don't see any option for builders.
The only option that I see right now,
and I hope others can get awake from this dream is that this is the only
option and I'm happy this is my belief if you strongly believe in Web3 this is
the only way we can work to make it a reality and not just a theoretical
things that is being around for a a while and and became all sorts of things
beside the the the vision and just meme coins and things like that. No we are
trying to build something that is a system that can run anywhere with for
everyone without any central control entity and we have open golf we have
this chain being built we have the greatest amount of talent doing it.
And we are just trying to convince more people to join
because we know there needs a lot of people to build it.
And the more of you that comes with us, the faster we will get there.
Yeah, absolutely.
This is the dream with Polkadot and now Jam compared to L2s,
is that we would have to be able to build protocols that
would decentralize and censorship resistant.
I think there's still some design that needs doing,
because it's not obvious that you can actually do that.
But we'll get there.
So from my side, I think Polkadot was proposed quite many years ago at this point. And it was one of the first large scale sharded blockchains.
And it was still a bit of a prototype of how a sharded blockchain should work.
And I think we got a lot of things right. And we also along the way realized that some things
could be better. And Jam is this moment where we can try and repay this technical debt of all the
lessons we learned and purge the whole protocol, simplify it, abstract it as much as we can, and do it right.
And I would say much closer to optimal the second time.
And I think the protocol being sometimes called hard to understand will be much easier with Jam
because we try to strip it down to as little as is necessary.
And I think it will help much in the future when it comes to understanding how it works how to build on it and stuff like that I
think this will be the main thing I'm looking for like repaying all this debt
we accumulated over over the years and I think it's a case for not just
blockchains but all large-scale software systems and not many of them has the
domain of them have the opportunity to repay this debt. And I think we are approaching a situation
where we actually can repay it and build something much better.
So I would say that we don't know yet still what
is going to be possible on Jam.
And we're hoping that some of the generalizations
will enable new things, right?
If you want to know what are the key inspirations for Jam
for moving beyond parachains with this core play idea that Gav had?
There's still like a branch of the
Polkadot Fellows RFC repo that, you know, never
went to pull requests. That's a very out-of-date, pre-Jam
idea for what you couldn't do,
for an idea that you couldn't do with parachains.
Maybe that would be of interest to people.
Yeah, maybe extra comment as well from my side.
It might be a bit of a hot take,
but I think if all that can be built on Jam
and all that will be built on Jam is just parachains,
I think it's a failure. I expect more things should be built and can be built on Jam and all that will be built on Jam is just parachains, I think it's a failure.
I expect more things should be built and will be built and we need to facilitate it.
And coreplay is one of the things I am most excited to actually be there and for people to use it.
Alright, thanks for all the comments.
I will walk around now and hand over the mic for anyone who wants to ask questions from the other panelists.
Thanks, Konstantinos.
I will refer back to the thing you said about Polkadot being the most decentralized or totally decentralized in comparison to the other blockchains.
Do you believe that institutions, governments, corps,
are ready to go fully decentralized or it's in their interest to have something like Ethereum
or another chain that has a point of centralization
in order to be able to control it or, you know, sensor, whatever.
Okay, I'm going to take this.
I strongly believe that one of the main use cases for GEM
are countries' infrastructure.
Because today, if you think about different
countries around the world there are only a few countries that can be really
sovereign in terms of technology today because they will rely on any
centralized infrastructure like Google or Amazon or any cloud provider that can
host their infrastructure.
So if you are like a middle-sized country
with, let's say, 5 million people,
only a few countries are big enough
to build its own infrastructure.
And even if they build, like, I'm from Brazil.
In Brazil, there are 200 million people there.
And even Brazil is
is not catching up. You can't catch up with like Amazon infrastructure or
Google infrastructure. So in the end all these small countries will have to trust
another big country like China or US to host their infrastructure. If these
countries start to use blockchain or gem as their own infrastructure they
don't care they don't need to care about it anymore
because they can host on a decentralized,
self-sovereign infrastructure that they can trust.
So I strongly believe that it's quite the opposite.
Polkadot is the only solution for this country
because if they are trusting Ethereum,
they would trust the two centralized stakers of Ethereum
that are hosted in the US.
So in the end, these countries won't be sovereign.
So the only sovereign solution for countries
is Polkadot and Jam.
Hello.
Most of the projects in the implementation today are not like open and like not something
that we can snoop and everything. Let's say that I am someone that is finishing an intensive
course of two and a half weeks where we learned a lot about Rust and a lot of nice stuff, how can, how could I
contact one of your, one of the teams, maybe try to contribute somehow in this case?
I don't have a full answer for that, but I can add some extra tidbits that might help.
So if you go on the gray paper page, I mean step one is after PPA,
sit down with the gray paper, take a read through it.
You don't have to understand it fully
because then a lot of people will give up.
Just give it a small read.
And then on the gray paper page,
there is also a separate tab
that lists all the implementation and teams
that wanted to be listed there.
Not all of them have contact emails, but a lot of them do. But all of them have contact emails but a lot of them do
and but all of them have at least a name. Maybe you can google the name, they have a Telegram
account there, message them. I think there's like 40 or 50 percent of the teams that are listed there
have some contact method. So if you want to specifically join one of the current teams,
this is the way. Or you know interact with some of your students from here or other people and start your own team a lot of
different options this is like a partial answer
yeah thanks so you can always join elements and on the website that much I
mentioned there are also links to the element channels.
There are two main channels that are of the most interest.
One is a gray paper channel where the stuff about gray paper is discussed.
The second one is Jam, which is more kind of general about Jam.
And then you can do a shout out there and all of the Jam implementers are there and usually at least maybe not all of them
but some of them have their own channels which are related to their own implementation that you
will most likely get invited to and then you can take it from there because yeah it's it's not a
there's not there's no like let's say a clear path path for every team and the same path for every team.
So I think it's best to reach out to the leaders.
Yeah, and because there are 35 teams, probably some of them do not accept any external contribution.
But I'm pretty sure there are plenty of teams that you can join.
And just by exploring, you choose the language, try two or three
and see if you can get in
and based on that
you follow up. If you can join any team
just raise a message
and say oh I could enjoy any team
then build your own team and go for it.
Yeah back to
I want to catch up with Konstantinos' question
because I think it's a really important topic, like institution, of course, one always like a little bit of control. And I mean, my, my instinct would say, like, just, just get, you know, dot tokens. And if you have dot tokens, you have more power in governance. But the thing is, like, as far as I understand, the dottoken will be mainly on the Polkadot hub,
which will be the service for parachains, right?
While this lower-level stuff for gem, how will it be controlled?
Because it's a debate, because the token holder will probably understand nothing about these upgrades,
so should they have a say on this?
And how do you envision this if there is already
there is some sort of discussion?
Because I think this is a really important aspect of GEM
that hasn't really been really addressed so far,
as far as understand.
it's a difficult question
because it's essentially a question how will governance evolve in jam from the way it works
right now and and it's like we can share our opinions but it's not really up to us because I assume
governance and dot holders will be ported all over to Jam and they will somehow
participate in either broadening or making their control narrower based
partially on their votes and they will no longer be able to just vote on the
runtime upgrades of the beacon chain relay relay chain, jam chain, because it will not be upgradable.
But hard forks are technically possible in the future, and fellowship will still be involved.
So my opinion is that it might make fellowship more important and relevant.
Especially because fellowship and jam
are not totally separated and jump rise has some mentions and incentives that
if you start building those implementations you might potentially
have some benefits and speed tracks to get into the fellowship so they're
essentially trying to funnel all those experts building those jam
implementations into the fellowship,
hopefully creating this DAO that can vote and create the future of the protocol.
And the fellowship is then kind of contracted by governance.
There are proposals and they are essentially obligated to listen
to some of the votes coming in from governance.
But this is an opinion of one person. I think many different people will have
different takes on the subject. Yes, we don't know. The situation will evolve so
we don't know if there will be token votes that will be important or not. For
sure, yeah, the fellowship will be more important. The diversity in
implementation, maybe that moves us a little bit closer to the Ethereum's thing with its downsides of
having to wait five years for one team to do this particular thing. I
presume we'll try and be faster than that.
But, yeah, we don't know.
Fellowship will be important. Maybe that we vote.
But actually, it's a it's quite an interesting question because we don't know but if you look around
the options are even worse because we we at least we have open gov for something.
No other chain has beside let's say Cartano or whatever chain has some some kind of governance.
There's no governance at all. So token holders anywhere don't get decision
on any other chain.
And Polkadot at least has the possibility,
if we build something that we can manage,
to do the voting connected with whatever upgrades or things
we can do.
It's hard to do it, but it's the only option.
So there is no other path.
I don't know if I said something that is wrong,
but this is how I see.
Yeah, so if I put my engineering hats again,
actually I never take it off.
I mean, like, parachains will still be able to forklestly upgrade, right?
This is not a functionality that most likely will be taken away.
Then the fellowship, it's still, I think, I mean, I guess we don't know, but my prediction is that the fellowship is still going to be kind of subject to the open governance.
Open governance will be part of the service.
It doesn't matter which one.
Then services will be permissionless.
That was the promise of CHAMP.
So everyone will be able to create new services.
new services. I'm pretty sure that from the engineering perspective, there is nothing
preventing us to create services that will be able to replace their code, right? So services
will be able to have some sort of upgrades as well. Now to progress services, to run services,
you will need to have core time. So the question is like, okay, how do you obtain the core time and
how do you pay for it?
My, maybe not like a super wild prediction is, well, it's going to be the dot token still.
So you can see how this all is still evolving around like the dot token, the governance.
There are new primitives that kind of show up here, but I think open governance will still control pretty much everything.
Well, yes, there's not going to be a way to forecastly upgrade the Jam protocol,
but, well, yeah, the technical fellowship will have this as its mandate, and then it will be controlled still through OpenGov as this, like, I would say, highest authority.
And also, we are building an infrastructure.
So the fact that the infrastructure is resilient
and censorship resistance doesn't prevent anyone
to build something that is still centralized.
You can have a service, and you can say, OK,
I'm the only person authorized to actually execute
something on that service. and that's totally fine.
We're on time but I think there was one more question that's let's address and
then we wrap up. Thank you everyone for the speakers. It has been a very
interesting discussion so far.
Still around this managing Jam and its future with Polkadot as well.
I've heard about this Jam implementers DAO.
So for you guys, especially who are in this DAO, could you probably elaborate more about this,
like the objective and then your wishes for the futures
because I'm assuming that for these members,
you're also building Jam
and you would like to also be able to, you know,
carve the futures of Jam in the next,
let's say five or 10 years.
Yes, so the Jam DAO is something really, really new.
Actually, it was kind of created in the last couple of weeks,
so it's pretty, pretty new.
But the idea, the core idea is that there is this Jam price,
and the Jam price will be paid in DOT,
and the DOT price will be paid in dot, and the dot prize will be paid in locked dot.
So there will be a lot of dots in the hands of gem implementers locked, so there will be a lot of voting power on the hands of the gem implementers.
So the idea of creating the gem DAO was, okay, so we are going to have a lot of power, voting power, on Polkadot OpenGov.
So we need to start to coordinate ourselves and to know each other and to get involved a little bit into the other proposals and read and understand.
Because we are actually, I speak for myself, I know almost zero about OpenGov.
And as a developer, as a pretty ordinary developer, I don't like it too much.
So I don't want to get involved too much in politics and things like that.
But this is something necessary in the end.
After quite some times working into it, we all know that there are some decisions that needs to be taken, and we want to be part of it.
Otherwise, others will decide for us.
If we don't decide for ourselves, others will decide for us.
So the Jamdown started as this idea, okay, let's test the beds.
Let's create this organization.
And it's not that much organized right now.
But the idea is that as we move on, we get more people involved, we can vote for the benefit of
the protocols, and for the things that we believe as builders for the future of Web3. So this is
So this is what we are doing right now.
what we are doing right now.
So I was actually told there's time for more questions if anyone has, so yes.
Yesterday I had the chance to ask Gav about this distributed data lake or the parts that are error sure coded.
And my understanding was that most of the data that we use to compute comes from that data lake.
And the thing that only gets accumulated is probably the commitment to the data in a form
of a hash so my question is in that case we essentially use the data lake as state but my
understanding is that the data lake is pruned after 24 hours because the error sure coded chunks are pruned after 20 at least in the current implementation
uh so does that mean like our our funds are lost after 24 hours like of course not
so it i presume you've all learned how it worked in polkadot uh it's the same situation
I presume you've all learned how it worked in Polkadot.
It's the same situation.
The things in Polkadot that we put into our data availability
are the POV blocks, the parachain blocks as they come along.
So the state updates, not the state of the parachains themselves.
And if the collator of the chain doesn't share it,
you as a collator can get it from the data availability.
If you have a power thread,
which has one guy producing the blocks,
and that guy loses all his data,
then you only have access to the last 24 hours of blocks,
and then if only if
someone's getting it. It's possible that some node that was sort of following
this before and it doesn't update in 24 hours, then you lose the data. It's
exactly the same problem. Now what we hope, but with Jam we're trying to move
beyond chains so it will be more like the power thread situation if you're not a parachainer. If data disappears and no one
backs it up then yes you're in trouble, you have trouble. But what you would
expect, what we'd hope is to build up a whole service beyond just the validators of Jam themselves, who
will be getting this data, parts of this data, and storing it for longer than 24
hours. So hopefully you'll be able to get hold of this data knowing just the
information you're using to get it from the validators for a longer period. But
that involves building something that's not been built yet
because we even have these guys trying to build the validators
and like lines and things.
But, yeah, hopefully, all this data will be available forever.
I think it probably already is for PokéDot.
So that means and then we still have to run like dedicated infrastructure in the form of collators and block builders for our services.
So the only services that are technically possible are parching like services.
It's not like fully a smart contract where we deploy bytecode and we forget about infrastructure. It's not true.
We can store all your state
on the data availability.
But to have it more than 24 hours,
you need people. But the people that you
have storing this,
they needn't be limited to
storing the history of just one chain.
Right? And they needn't be storing
everything. Because we've already
done this eradasure coding.
And this means that we could have, we could switch to more to the sort of like client thing,
with the erasure coding that Ethereum had been talking about,
where you have lots of full nodes, like clients, whatever, that aren't validators,
storing parts of this data for the long term.
And that would allow you to use this recovery mechanism that we have.
But to get your pieces of radio-coded data from beyond validators,
you should be able to get hold of it forever.
But yes, someone will have to build the infrastructure,
but it needn't be centralized or associated with a particular chain.
My only concern is then we have the same game theoretic problem where we have to incentivize external parties to hold our data. base layer chain with Jam is it will guarantee like security for state transition it will not
ultimately guarantee that we'll have like liveness we have to incentivize other people to hold our
data for forever don't hold your data yourself you always have to incentivize other people to
hold the data um and and it it's the possibility of it being decentralized
of everyone having small pieces,
which isn't expensive.
This is not an impossible problem.
We needn't be relying on some centralized service
during the history of everything ever.
But of course, we always have this problem.
With validators, we're incentivizing them to hold the data as part of the system,
but they can't hold it forever or else our requirements will be crazy.
And also on top of that, something like polka.hub will probably still be present in Jam.
If you just want to have a smart contract,
someone else will do the incentivization protocol
on something like polka.hub to run the collator in Jam
and you can just forget about it and do a smart contract there.
Like this will be an option
and it seems like this is what you want
and this will be there.
You just don't want to run a parachain, then do this.
So I think the important thing to note here is that the requirement is still there,
but Jam relaxes this requirement and gives you a control over this.
So if you want to have everything on chain, well, yes,
but then you are constrained with whatever you can accumulate and you have to pay for this.
Or you can move on the other side of the spectrum and have
everything in the in the data lake but then yeah you have this issue of okay I
don't I need to incentivize someone else to store that data right and and pay
accordingly
What are the QN functionalities or features or needs that users have that are not possible with Polkadot and we need to move the job?
I mean, the first one that will come to mind, and this is something I don't know that much about,
but the idea with Coreplay is that you can have, as far as I understand, some kind of an unbounded execution
that will eventually slowly execute on chain over the blocks.
And some of the promises where you can just write normal code with for loops and stuff like that.
Maybe some of those promises were a bit optimistic. I don't know what's the current state of core play,
but ideas like that were being discussed. And this might be possible on Jam.
And as far as I know, it's definitely not possible right now.
So I'm not so sure about this. I actually think the answer to this is no, nothing's not possible,
but some things become a lot easier.
And the whole performance goes up, right?
Particularly of things like CorePlay, which would be, you could do them on parachains, but you'd have to,
so you'd have to put things in parachain state and you'd have to get stuff from the state of other parachains.
The coordination problem is not necessarily all that much easier.
We can do all this with parachains, although people aren't.
And people have failed to move beyond the model of parachains
where we have one team and they go and build one parachain,
and it probably does the same as every other parachain.
This is not really what we...
Some of this was built into Polkadots.
The sort of assumptions,
like the way we had the crowdfunding stuff
almost replicates the ICO boom,
almost replicates the ICO boom, which was maybe not a good idea.
which was maybe not a good idea.
But all of this was already, like, I don't think people are using Polkadot to its full capacity.
And with the new features that are coming to Polkadot 2.0,
we'd already be thinking about moving beyond what we can do with
parachains and Jam is going to be the next step of making it more general but
in the end yes there is nothing that we couldn't have done with parachains but
people weren't doing them
I wanted to ask a little bit about asset hub migration in context of gem because as far
as I understand the reasoning why currently there is a plan to migrate governance and
tokens and a lot of stuff to the asset hub is because in the preparation to the gem because
then everything will be on the service but my question is
gem will be running under the runtime right we still will have a grand pine
stuff we still have like this core VM the general virtual machine which is
gonna be running why we can't have governance there why we need to bring on
the separate service and actually bring all the security assumption that was
just talked about right that, that if data lost,
data lost, if nobody's running the collator
for a service, not collator,
but whatever they will be called.
So let me kind of address the things.
The core VM service still needs to be run by someone, right?
To progress, it's not like inherently in Jam
and you just deploy something and it runs.
Like it's a service.
The service requires the core time
and someone has to provide that core time
to execute your service.
And how, like who's going to be the person who actually provides that core time and executes
that service that's not defined. The validators will obviously make sure that it was run correctly
but you still need to figure out like let's call them collators as we call them right now
like what is going to be a collator network and Gav actually mentioned that yesterday
Asked about the the core play like what would be the kind of proposed structure for for for core play?
So you can probably like look up the recording. I'm not gonna be
Kind of repeating that and and also to address the second thing about like why this thing cannot be just run on core VM.
I mean, it's a process, right?
And the first and the kind of from the implementation point of view,
the simplest way forward is, okay, let's take everything that we have right now
and let's try to run this everything on Jam directly.
And from there, or maybe even in parallel,
we can start taking some pieces of whatever we have
on Polkadot right now and maybe,
okay, let's make this a native service,
if it makes sense.
So is the question more like,
why do we want to have a minimal relay chain
in the first place and not just put everything on it as we are going to do with Jam.
So it's clear we need to migrate Polkadot
away from the relay chain in order to switch to Jam
but why don't we put everything on the relay chain to start with?
I mean, aside from the fact it's not really scalable.
And yes, this, well, because we want to make,
one of the chief reasons behind Jam
was to make the central protocol of Jam,
or indeed of Polkadot moving stuff off the relay chain,
was to make it comprehensible.
You know, we want to make things modular.
We weren't really having that if everything's on the relay chain.
Yes, it comes to an issue with liveness and censorship,
and I think we should be looking more at that.
With the asset hub migration coming up,
I'm certainly very invested in making sure.
So the answer is we need a diverse collector set right we need lots of full nodes of
asset hub now so that this data doesn't go missing we need a diverse set in
order and we need to make sure that we are consensus etc is censorship
resistant because otherwise it's a downgrade from polka dots a thousand
validators sure I mean I I think we would want governance to be somehow downgrade from Polkadot's 1000 bar data. Sure.
I mean, I think we would want governance to be somehow upgradable, like how it operates in the future.
And if we would have it baked in into the core protocol,
which, as we decided, is not upgradable,
that's a bit of a conflict of interest.
So the conclusion will be, okay, make it upgradable.
We don't want to do it.
A lot of confusion, a lot of complication.
As Alistair said, we want to make it as simple as possible
and as modular as possible. And on top of that, wasted lot of complication. As Alistair said, we want to make it as simple as possible, as modular as possible.
And on top of that, wasted work if we do it
on the relay chain, jam chain or whatever, as a core part of it.
Hello.
During the session, you mentioned how much the jam will influence the Polkadot development and the relay chain.
But do you know what would be the impact on the broader blockchain market with Jamset standards?
What do you think about that?
Would it become maybe an industry-wide standard in the future?
industry-wide standard in future?
I mean it's a question that essentially forces us to make a bet.
All of us are working on it because we think it has a chance.
Is it the way I would like to phrase it? At least that's how I think about it.
I think we noticed in the past,
especially with the Polkadot hub and asset hub migration,
all of that, people like doing stuff in Solidity.
So we are giving them smart contracts in Solidity on Polkadot.
And this will also be a part of Jam.
We have a lot more bridging coming over
that will allow people to move stuff from Ethereum or other ecosystems.
So I think if Solidity is what they wanted, they will have it. If high throughput and lowidity is what they wanted, they will have it. If high
throughput and low price is what they want, they will have it. If some people still like doing
power chains, they will have it. I think we will have a lot of different things that might target
different niches and different audiences. And what I can say is I struggle is, if we have solid smart contracts and all of that,
I struggle to think of a part of the ecosystem that will no longer have the tools to build what they want on Polkadot.
It is true that we started off with a technical advantage and we're doubling down on that.
Maybe Polkadot has issues with the user friendliness
of deploying stuff.
And it's really important that people
start building that for Jam if this protocol is going to succeed.
We know that.
Everyone knows that.
And then, yeah, we hope. then yeah we had
thanks my question is not really technical I'm just wondering how many of the implementers teams are really committed
or committing to deliver a production-ready node, jam node?
I mean, maybe it's just let's try,
let's deliver just the milestone X,
but I want to know, do you have any idea of teams
that are here to deliver the thing?
Yeah, it's really hard to answer this because it's an open protocol.
So there might be like hundreds of teams working in the cave and it's really possible.
But from at least my perspective, so if you go to the Gray Paper website, you have like 38 teams that officially
announced that they are working on it. And from those, you see a smaller group, let's say 20 or
25, they are interacting in the chat and asking questions and making some kind of comments,
so you see that they are active.
And we have these Jam meetups that we are organizing
that the teams that are more eager to go there
and stay together and coordinate in some way,
like teams that are participating of the JamDAO,
something around maybe 15, 20.
And from those, probably most of them
will get up until at least milestone three.
Of course, going up to milestone five
is very much dependent on the next steps.
So I would say after milestone one
and two we'll be able to answer this question more safely. But my guess
is that we are going to have at least eight good implementations of Jam, which
is far more than any other protocol ever. This is my guess.
If we can make a bet now and after five years,
we can get a prize for those who get the right answer.
But it's just a guess.
Well, people are saying that you still have time to get in.
I think you probably still have time to reach
milestone 5 at a competitive thing.
Yeah.
Yeah. If the underlying question is, can I get the prize?
Yes, you can.
If you want to join and...
What I worry about is, are people offering enough for milestones 4 or 5?
Because that might determine who gets in.
We still, like, I'm still worried that the gray paper doesn't really fully specify consensus
and everything and no one is building that yet.
I agree.
It will have to.
But I think the more people, the further we go in the implementations,
the more questions will arise in all those chats
and we will slowly specify it
because I think it was already happening in the previous milestones. People were asking a bunch of questions, like, hey, isn't this a bit ambiguous?
And things are getting clarified. And I think we are getting more and more into the core
consensus parts of ELLs and everything. And I'm excited that we're slowly getting there.
So, yeah, I kind of echo what my predecessor said.
And I also agree that we are yet to see how many teams,
and it's going to be easier and easier to assess,
because from my personal assessment of the milestones,
the jump between milestone 1 to milestone 2 is probably the hardest, I would say.
And after milestone 2, there is still a slight jump milestone one to milestone two is probably the hardest, I would say.
And after milestone two, there is still a slight jump
into milestone three, which is getting
a decent performance.
But after that, I think when you see a team reaching
milestone two, then it means that they are super committed
to take it all the way.
And when someone reaches milestone three,
then I think you can be sure that they are going all the way and when someone reaches milestone 3 then I think you can be sure that they are they are going all the way.
Something related because I you know I just hit the lectures yesterday and today
so I'm not too familiar with the milestones right so it says like if you
say milestone 5 doesn't mean anything to me at the moment. Okay. And you said that
some of them are not clarified so it's like how you say minus two five doesn't mean anything to me at the moment. Okay. And you see that some of them are not clarified.
So it says like how many does the gray paper clarify and how many does not?
Okay, so milestone one is to import blocks.
Basically to correctly implement the state transition function.
It's not the whole protocol, but it's like half of it.
Guessing, but something like that.
Milestone two is to build the complete node,
including the off-chain part of it.
Because there's a lot of things that goes off-chain,
like guaranteeing the state, the data availability layer,
and things like that.
So there's a lot of things going on off-chain
and implementing networking, communicating with other nodes.
So basically, if you have Milestone 2,
you have a node running with everything specified.
Milestone 3 is make it
as performance as Kusama,
which means it's usable at least in a test environment
milestone four is like production ready like polkadot in terms of performance and milestone
five is being audited by a someone that will audit and say okay this is really a safe software to run
via someone that will audit and say,
okay, this is really a safe software to run,
and you can run anywhere.
So these are the five milestones.
So basically, milestone,
I don't know how much milestone five
depends on the team itself.
Probably the auditing will save some feedback.
You have to change,
you have to follow all the audit rules
until you get it.
But three and four are performance,
and one and two, one
is just block importing and two is full node even if it's poorly performant.
Thank you very much. The second question I have is there is an incentive for
people to build various implementations of the protocol now. What are the
incentives to keep having like a diversified
ecosystem after the prizes and everything is gone in a sense, right?
Actually, I can briefly answer that. So the part of the Jam Prize is also like a promise of
promotion in the fellowship. So we want most of these Jam implementers, especially the teams that
go all the way through, to be able to have all of their members, or at least their key members, part of Fellowship.
And Fellowship is one, if we're purely talking about monetary incentive,
Fellowship also comes with monetary incentive.
We can also think of it in that, as mentioned by then,
if a team has implemented all the five milestone,
they also have a lot of lockdots given to them as the part of the prize and generally you know developers who this gives an incentive
for all these developers but you know not only that but I would say with
almost sure that if you build gem up until milestone 5 you were capable of
doing a lot on top of it and you can make a lot of proposals to open
Gov to improve the chain and get some monetary funding for your projects.
So basically you have all the knowledge that very few people have to build
other stuff on top of blockchain on top of Jam and Polkadot. So you have the
power to propose things that people will see, oh, this is a good project,
and he or she has the knowledge to build it
and has the reputation.
So you build the reputation,
and then with this reputation,
you can get funding for whatever you want.
So basically, after you build Jam,
you'll be probably in a good position
to ask for funding for anything
that you want to build after.
Yeah, to follow up on what Kian said,
I think the rules say that for every milestone that you submit,
one of the members of your team can be proposed for rank three of the fellowship.
And also what Kian said as well regarding the incentive there,
I would kind of expand on this because I heard it mentioned today and yesterday.
It's like being in a fellowship. It's not like a club where they a JAMM implementers joining the fellowship,
their mandate, I suppose, will be, okay, keep the implementation running. Or if we decide, okay,
we don't need so many implementations or they are redundant or for some other reason we don't have
resources to maintain all of them, then kind of gather together and create like one or join forces and maintain one implementation
or couple of implementations out of all of them that are there.
And maybe just to be clear, the mystical incentives in the fellowship is just a salary.
Like you're getting a salary from the fellowship.
Yeah, and yeah, I didn't mean only monetary like incentives, but also like what would be the incentives to have diversified clients and not, you know, in the sense maybe we end up only having one again.
And, you know, I think the goal of the time is to also have diversification on the client side, right?
Are you asking is what's the benefit of having multiple clients?
No, no. What are the incentives? Like why people would use like the X client and not Y client?
Actual validators running the hardware.
Yes, exactly.
Why wouldn't we end up like only with, you know,
the best Rust implementation or the best whatever implementation
and nothing else is used?
So I have like two answers on this or two kind of possible
scenarios that I can imagine.
One is, well, you would pick different implementations just because it creates more resilient network.
So similarly, I think there was a situation with these Bitcoin mining pools, and one of them was reaching the 51% threshold.
And what people did, they actually withdrew money
from that mining pool, even though it was paying the most.
So kind of Bitcoin fall back into this like social consensus
where people said, okay, we don't want this mining pool
to have 51% of the hashing power.
So we are withdrawing our hashing power from that pool
and we are moving it to someplace else to make sure that it's
Maybe not super evenly distributed
But definitely to avoid the situation where we have one implementation running
The entire network if there is a bug there or something happens then then we are screwed, right?
So so that's one of the reasons and the second reason, I think, it mostly depends on the Jam implementers,
and it's in their hands.
I can imagine that the implementations will provide,
will kind of specialize into some of the,
like, in some particular mode of operation, let's say.
Or in, like, some might be more optimized for running on Apple
Silicon, for instance, and some other might be faster
on running on AMD processors.
Then we can have implementations that give you
some additional features.
I don't want to say like MEV-related stuff,
but perhaps, right? So it's also a path for the Jam implementers to innovate here
and propose some features that are unique to their implementation.
I have just another complementary thing is that
because each implementation is done in different programming languages,
each implementation is engaging different communities because we all know that each programming language has its own community. And we are building in Elixir, so probably we'll engage more Elixir developers to build on top of it. And because of that, after some time, each team will want to keep the version running
because they can work with their preferred programming languages.
We are developers.
We have our favorite programming language,
so we wanted to keep it because, yeah,
it's the thing that we want to work on,
and I think this is an extra argument
for keeping different programming languages
and communities engaged on top of it.
I mean, I'd point out the obvious again, but just because 95% of validators
are running this implementation right now because it's more performance and they get more money
doesn't mean that in two years' time it's going to be the same. Hello, and Pablito.
Earlier today, Tomek shared that his team created a tool for reading the gray paper.
I wanted to know if there are other tools that teams have created and that other teams
are sharing and using right now, if of those like emerge also from from these collaborations and if not like if
there's anything that you would love to see an element message saying hey everyone
we created this and we're sharing it but what what do you guys have created and
what do you guys want to see from other teams or maybe like emerge from this
collaboration I think the one that I saw there are not so many so there's teams or maybe like emerge from this collaboration?
I think the one that I saw, there are not so many. So there's plenty room for innovation in this side, I think.
I speak for myself, for our team.
We are so much occupied building
jam that we don't want to waste time, at least right now,
with other stuff.
And we are still a small team, just two people.
So depending on the team, you can spend more time on tooling and things like that.
But as time evolves and you complete the milestones,
you can increase the team size.
You can afford to pay for other developers to join the team and build other stuff.
But up until now, I saw that the PVM run it.
I think Fluff Labs is doing amazing work with this.
And there's this PVM run it, I think Fluff Labs is doing amazing work with this. And there's this PVM runner, so you can run in the browser.
I think you showed something like you can take any binary PVM compatible
and run in the browser to make a simulation of the run of the code.
There's this PVM, the gray paper reader.
And one thing that I see that I saw that is not built,
but it's something that anyone can build,
is that GEM will have internal statistics of the node that
are running the services.
So there's a lot of data that will
be kept in the state about metadata about the gem chain. But there's no way to visualize it outside the
like let's say the logs or things like that. So creating a visual interface
where you can see that the chain, all the nodes running, what are the nodes, what
they are doing, and making some visuals of the Jam running is something that is
it might be interested if some people are like you if you like interface and
visuals definitely something that it's gonna be needed in the in the short term
when you start to run the testnet.
Yeah yesterday Gav shown the Jamtop tool that he developed or someone from his team.
Jamduna team has like a converter between JSON and Jamcodec, I think.
And then the Grey Matter team is actually maintaining a whole documentation website.
I think it's Jam jam.in, right?
And there is documentation, there is some kind of excerpts
from the gray paper and also links to other resources.
Something that was mentioned on one of the Jam implementers calls
is this kind of search engine that would be able to index
all of the messages from Element and, yeah,
like make them searchable because I think for many people,
the search on Element doesn't really work that well.
I can also add something small here.
One of the requirements of the Jam Prize is for the teams to demonstrate the history of their commits
and, you know, that there there's nothing weird going on there,
that it's coming from the authors and it wasn't all done in one commit or something.
So we build a tool that is running as a GitHub action and
on every commit posts a remark on AssetHub or
one of the system parachains with the commit hash.
So we have our Git history actually published on the
blockchain. And this is public. I don't have a wish list. I don't have a wish to share.
You mentioned earlier that user experience is currently a little bit lacking in Polkadot.
Experience is currently a little bit lacking in Polkadot.
And my question is, how do the Jam or let's say the Jam era going to address this issue?
What do you envision for Polkadot in terms of user experience in the future?
I think it's something that is not in the scope of Jam.
It's something completely out of scope of Jam.
I agree that there's an issue with the usability.
We need to improve it.
But Jam is a lower level.
It's just like we are building the road.
So how the cars that will pass on top of it
and how they will manage to the traffic
and what colors the cars will be doesn't matter for Jam,
at least.
What we know is that, of course, we
have a better road with very soft, let's say, asphalt that you can run on top of it.
So probably the other layers built on top of it will be promising, but nothing that is guaranteed.
Better experience for developers.
But this is something that needs to be built in parallel.
Yeah, I completely agree.
And I think it's just the answer to that is not jam.
It's the work being currently done on polka.hub, all around it,
polka.app, and all the other tooling around it.
Like, this is what's trying to address your concern,
which I also think is a real concern.
I don't think it's a real concern.
I mean, it's like I'm pretty confident that the current state of user experience on Polkadot is way, way better than it was three, four years ago.
I mean, I remember when I joined the ecosystem, there was only Polkadot.js.
And it was a very horrible way of interacting as a new person.
horrible way of interacting as a as a new person and now you have like nova wallets sub wallet and
all these like mobile possibilities that are i think top-notch products and you have now the
soon the the polka.app coming up so i think like these things will not change. I mean, Jam is changing on the lower level.
So we still have Polkadot, and you
will interact with Polkadot with these tools that can improve.
But I think they're already very good.
So add maybe a tiny bit to that.
I definitely agree.
The wallet situation has gotten much better. There are big improvements, more work to be done.
But for instance, by having Ethereum smart contracts on on Polkadot Hub, we can start benefiting from Ethereum tooling, Ethereum IDEs and stuff like that.
And I don't know how much work you all have done on like Solidity smart contracts in this course, but we already have some prototypes and forks
of Ethereum tools working on our side,
so we can benefit from their side of the ecosystem
and use the toolings that people actually enjoy
on our side.
Yeah, I think also worth noting is that
there might be two streams that will happen in parallel.
So everything that happens now on Polkadot,
hopefully it's going to be migrated as it is on Jam.
So we will start with, or we will rather continue with what we have
and we will continue improving it.
And then as Maciej mentioned earlier,
for services that are yet to be built on Jam,
I would actually argue that it might be even harder
to build a good UX product on Jam
because there is a little bit more moving parts there.
Yet still, we don't have to start with any technical depth.
You start fresh and you can start building this stuff.
And I think it also depends on you guys and other builders that that will
create services and and
First as the case that will allow to build on jam
Like what this user experience is gonna it's gonna look like in the future
All right seems like we have run out of questions.
So thank you again to all the panelists
for sharing their insights.
Thank you to the audience for the questions.
Congratulations again.
It's the last day of the Academy and the last,
I think literally the last piece of your mandate here.
So go rest now and yeah, have a good evening.
