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:35:17Space Recording
Short Summary
The Polkadot Blockchain Academy's live stream highlighted the launch of Jam, a new initiative aimed at enhancing the Polkadot ecosystem through innovative projects and partnerships. With a focus on community growth and collaboration, the event showcased the commitment of developers and researchers to build a decentralized future.
Full Transcription
Hey everybody and welcome back to another live stream here at the Polkadot Blockchain Hey, everybody.
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.
Kian Paimani- 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?
I will go last.
Oh, you're last.
Also, I have a teammate who will 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 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. You also said why Fluffy Labs, the name.
Why Fluffy Labs?
Oh, why Fluffy Labs. I was trying to come up with some name that is, you know, kind of,
yeah, like, funny, because everyone was coming up with names that are, like, super serious,
you know, like, this mathematical structures kind of labs and something else.
Four more specified. Like this mathematical structures kind of labs and something Formal specified
Fluffy labs can also be like fluffy labradors
This is why on our sticker we just have a dog
So that's that's that's the idea it should it was supposed to be fine
Okay
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, E eu também, às vezes, aprender mais sobre Jam, porque estou aprendendo o que estou fazendo.
Eu...
Stop? Não? Posso fazer isso? Tudo está certo?
Eu também compartilho alguns conteúdos sobre Jam no Twitter,
para que as pessoas possam entender o que estamos fazendo. 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 on top of it. So it's a really fun time for me.
of the grey matter team and we are 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
outtakes 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 we, I think at this point, can, as a team that all is working part-time,
accept 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 who have tried to believe, that this will be the future of Polkadot.
I think it will provide further abstractions to stuff we can build and open many different
avenues that were not possible before.
Hi, I'm Alistair, lead scientist at the Web3 Foundation.
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, like, gain knowledge of the protocol,
especially in the first two milestones of the prize,
such that I can, you know, keep myself up to date
and have further avenues of contribution and is actually in production. the first two milestones of the prize, such as I can keep myself up to date and
have further avenues of contribution, and it's 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 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 just to change the job order yeah so in my case I think me and
Yeah, you can make it just to change the order.
Kian being in the same 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.
And this, do you also want to comment on maybe what do you find interesting about Jam?
That's a different question.
Why are you here?
Why, why, why?
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 grey 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. 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 how you're doing.
Okay.
Sorry, I wanted to add something.
Like, purely from the engineering point of view, if you look at the project, at the Jam 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 of,
I came out of PBA after doing PBA,
I knew that I wanted to build something on top of,
on Polkadot, something related with Polkadot,
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 Jim, because even if we don't finish and if we don't get the
prize we'll get so much knowledge and so much connections and 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'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, 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 is like, for me at least, it's a long-term journey.
It's not a like 100 meters race.
It's a marathon and we are just in the first kilometer of like 42.
So there are still a lot of roads to run and everybody is still very welcome to join the
the boat for like in the at least in the next five years is 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 And give your experience generally working with the other teams.
Yeah, actually 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 see 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 let's try to figure out each one trying to
figure out its own bug so I think the community started to evolve from from
from these and now we are meeting we have a meeting in Lisbon everybody's
welcome in May we're gonna have our
Jam experience event and we're gonna
Try to launch the test net by then let's see if it's possible or not But yeah, we are working hard to to make at least a few implementations
test ready for for the gem toaster and
Coincidentally the gem toaster which is the data centers that is being built to run the test net or the
pretest net let's say so
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.
And we have at our disposal like a hundred,
I don't even know how many cores and memory,
like petabytes of disks and terabytes of RAM to run the project.
And each team running its own implementation and talking to each other,
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?
Like, 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, like 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 much as possible this is already something that's being worked on with the PBA PBA tries to spread the knowledge and PBA jump rise
and the fellowship is 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 Polkadot Fellowship right now is to hedge against any particular company being the development bottleneck or the knowledge now, is already like five steps ahead of that,
because 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 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 three, 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
PBM 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 2 but I would be happy if we reach milestone two and then for instance pivot into being in
browser lite client for for jam yeah for us elixir it's still a question mark if
we can make it for an up until milestone five I 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
Yeah, 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, have a customer, so basically I'm part of a community and working in 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.
Yeah, so I've been working and trying to share as much as I can we 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 the 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.
we can get all those different services all those different cores to cooperate
together and and this aspect of pocket is something I've been working all my
time in pocket in pocket 2.0 and I'm hoping to transfer this knowledge to
jam help all that are other teams not necessarily just mine but hopefully a lot
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 polka dots and I'm hoping that's like within a year we can
actually start working on elves and 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.
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, you know, 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 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 fork will be new, a little bit new in the Polkadot area.
will be new, a little bit new in the PokéDot 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 PokéDot 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
I have not heard. I don't know. I'm still thinking that
There's no real urgency with quantum resistant crypto, but the
Perhaps the important thing is not that we adopt it, but that we have a fork ready to go
right
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 we're 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,
and 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.
So, 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 will have to decrease performance somehow.
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 sassafras 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, block space, bandwidth, everything, rather than warmth.
You know, block 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 and it just improves the performance or it makes the entire system more resilient.
So 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 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.
To whoever from the panelists wants to address this, how would the upgrade path for the existing
Polkadot system and parachains would look like?
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 a
question to you do you know more than the rest of this I would say that I have no
idea yeah I have no idea. I have no idea.
I'm just building Jam.
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 just this is important I want to emphasize that
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.
So the first plan right is we build a core chain service that's capable of
running parachains on on Java and you build the Clayton stuff that they can
and existing nodes running probably cumulus as it is,
with your power chain built on frame,
will just be able to work.
Well, have the code, so that's just able to work.
And 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 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 polka dot 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.
So should 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.
Okay, 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
To open to start
So again, maybe from my purely engineering perspective
Like it's a really unique opportunity right now when we know that, 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
migrate the parachains and they're still going to be working.
But the question is, what else is possible,
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 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.
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 2's, you say, oh you have a lot of liquidity on base or 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 while and
became all sorts of things besides 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 for everyone without any central control entity. We have OpenGov, 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.
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 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 the years.
And I think it's a case for not just blockchains but all large-scale software systems.
And not many 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?
hoping that some of the generalizations will enable new things, right?
If you want to know, like, what are the key inspirations for Jam,
for moving beyond parachains, with this core play idea that the Gav had,
there's still, like, a branch of the Polkadot Fellows RFC repo
Polkadot Fellows RFC repo that never went to full request.
that, you know, never went to full request.
That's a very out of date pre-Jam idea
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
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.
All right, 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 censor, whatever. main use cases for Jam are countries infrastructure because today if you 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 five thousand five million people only a few
countries are big enough to build its own infrastructure and even if they be
like I'm from Brazil. In Brazil there are two
hundred million people there and even Brazil is
is not catching up you can 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
to host their infrastructure. If these countries start to use blockchain or
these countries start to use
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 they can't, if they are like trusting Ethereum, they would trust like the two centralized
stakers of Ethereum that are hosted in the US. So in the end, these countries
won't be sovereign. So the onlyations 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
that might help.
So if you go on the gray paper page, I mean, step one is after the PBA,
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 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% 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 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
Maciej mentioned, there are also
links to the Element channels. There are
two main channels that are
of the most interest. One is
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 shoutout 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 not a...
There is no, like, let's say, clear 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 base it 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, like, I want to catch up with Konstantinos' question because I think it's a really important topic.
Like, institution, of course, want always, like, a little bit of control.
And, I mean, my instinct would say, like, 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 dot token will be mainly on the
polka dot hub, which will be the service for parachains, right?
While this lower level stuff for gem, how will be controlled?
Because it's a debate.
Should the token, 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
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 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 chain, jump 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 price 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 JAMA 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 will be both.
But actually, it's quite an interesting question because we don't know.
But if you look around, the options are even worse.
Because we, at least we have OpenGov for something.
No other chain has, besides, let's say, Cartano or whatever chain has 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 hat again, actually I never take it off.
I mean, like parachains will still be able to forklessly 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.
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 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, I would say, highest authority.
And also, we're building an infrastructure, right?
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, okay, I'm the only person authorized to actually execute
something on that service.
And that's totally fine.
All right, we're on time, but I think there was one more
question that let's address and then we wrap up.
Yeah, 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.
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 future 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. but the idea, the core idea is that there is this gem prize,
and the gem prize 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 Jam 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 involve,
get involved a little bit into the other, like,
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 time 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 Jamdow 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 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 erroryrshire coded chunks are pruned after 20,
at least in the current implementation.
So does that mean like our funds are lost after 24 hours?
Of course not.
So 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, you know, 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.
And it's possible that some node that was 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 parathread situation if you're not a parachainer.
If data disappears and no one backs it up, then yes, 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
don't even have these guys trying to build the validators and like clients and
things. But yeah, hopefully all this data will be available forever. I think it
probably already is for Polkadot.
So that means and then we still have to run like dedicated infrastructure in the form of collators and block builders for our service services.
So the only services that are technically possible are parching like services like 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.
And they needn't be storing everything. Because we've already done this erasure 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 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.
And while the 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.
And 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
server storing 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 would be crazy.
And also on top of that, something like polka.hub will probably still be present in Jam.
Like 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 like 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, right? 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 to Jam? 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 is 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 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, you know, some of this was built into Polkadots.
The sort of assumptions, like the way we had the crowdfunding stuff almost replicates the ICO boom, 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 it. .
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 buy and stuff.
We still will have like this core VM,
the general virtual machine,
which is going to 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 if data loss, data loss, 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 the... 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 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, let's call them collators, as we call them right now,
what is going to be a collator network. And Gav actually mentioned that yesterday,
asked about the core play, what would be the proposed structure for core play.
So you can probably look up the recording, I'm not going to be repeating that.
And also to address the second thing about 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...
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 that... So the answer is we need a diverse collator 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 and we need to make sure that our consensus, et cetera, is censorship resistant
because otherwise it's a downgrade from Polkadot's 1,000 validators.
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 as module as possible and on top of that wasted work if we do it on the relay
change on chain or whatever as core part of it
hello so 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 Jam set standards?
What do you think about it? Would it become maybe an industry-wide standard in the 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 and I think we noticed in the past especially the polka that have an asset
hub migration all of that people like doing stuff in solidity so we are
giving them smart contracts in solidity on polka dots and this will also be a
part of jump we have a lot more bridging coming over that will allow people to
move stuff from a few more other. So I think if Ethereum, if Solidity 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 parachains, 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 to, 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.
We started off with a technical advantage,
and we're doubling down on that.
Maybe Polkadot has issues with 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 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 note jam note I mean
maybe it's just let's try let's deliver just the milestone X but they 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 we it's 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 great 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 there are interacting in the chat and asking
questions and making like 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 like 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 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 1 and 2 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 JEM, 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 know, you still have time to get in.
you still have time to get in.
I think you probably still have time to reach milestone five at a competitive thing.
at a competitive thing.
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 four or five?
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'll slowly specify it,
because I think
it was already happening in the previous milestones.
People were asking a bunch of questions and 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 ELS 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 into Milestone 3,
which is getting a decent performance.
But after that, I think,
when you see a team reaching Milestone 2,
then it means that they are super committed
to take it all the way.
And when someone reaches Milestone 3,
then I think you can be sure that they are going all the way.
Something related because 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 five doesn't mean anything to me at the moment.
And you said 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 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 set 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 a diversified ecosystem after the prizes and everything
is gone in a sense, right?
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 most of their all of
their members or at least their key members part of fellowship and
fellowship is one if it was purely talking about monetary incentive
fellowship also comes with monetary incentive we can also think about think
of it in that as mentioned by then if a team has implemented all the five
milestone they also have a lot of locked dots given to them as a part of the prize. And generally, you know,
developers who... this gives an incentive for all these developers.
And not only that, but I would say with almost sure that if you build Jam 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 golf 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 3 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 just get money.
It comes with the responsibility, right?
And the fellowship has a mandate of maintaining the protocol.
And obviously when you have a JAMI 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, like 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, no. What are the incentives? Why people would use the X client and not Y client?
Actual validators running the hardware.
Yes, exactly. Why wouldn't we end up only with the best Rust implementation or the best
whatever implementation and nothing else is used?
So I have 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's more resilient,
it creates more resilient network, right? So similarly as we I think there was a situation
with like this Bitcoin mining pools and one z nich włożyła 51%
i to, co ludzie zrobiły,
to, że wytrzymały pieniądze
od tego miningu,
nawet nawet wytrzymał się
z tym, że Bitcoin
wytrzymał się w tym społecznym
konsensus, gdzie ludzie powiedzieli,
że nie chcemy tego miningu,
że 51% hashing power,
więc wyytrzymy się
z tego połowę, i to wytrzymy się do 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 we are screwed.
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, right?
Then we can have implementations
that give you some additional features.
I don't wanna say like MEV related stuff,
but perhaps.
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 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,
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 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 have to 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, I'm Paulito.
Earlier today, Tomic 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 any of those emerge also from these collaborations?
And if not, if there's anything that you would love
to see an element message saying, hey, everyone,
we created this and we are sharing it,
what do you guys have created and what do you guys
created and what do you guys want to see from other teams or maybe like emerge from this
want to see from other teams or maybe emerge
from this collaboration?
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 are not, 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 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
Jam 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,
let's say, the logs or things like that.
So creating a visual interface where you can see the chain,
all the nodes running, what are the nodes, what they are doing,
and making some visuals of the gem running is something are the nodes, what they are doing, and making some visuals of
the Jam running is something that is, it might be interesting if some people are like, like
you, if you like interface and visuals, definitely something that is going to be needed 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 a converter between JSON and Jam
codec, I think.
And then the Grey Matter team is actually maintaining
a whole documentation website.
I think it's 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 implementer's
calls is this kind of search engine that would be able to
index all of the messages from Element
and 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 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.
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 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 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 not something that is guaranteed better
experience for 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.
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.
And now you have like Nova Wallet, Sub Wallet, and all these like mobile possibilities that
are, I think, top-notch products.
And you have now soon the Polkadot 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 like Polkadot and you will interact with Polkadot with these tools
that can improve, but I think they're already very good.
To 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 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 solid 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 good UX products 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 will create services and, first, SDKs that will allow
to build on Jam, what this user experience is going to 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. Thank you.
