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:20Space Recording
Short Summary
The Polkadot Blockchain Academy's live stream unveiled several exciting project launches, including Fluffy Labs' TypeBerry and Gemixir's Elixir-based Jam implementation. The panelists discussed the growth of the ecosystem, emphasizing community collaboration and the importance of decentralized expertise, while also highlighting the potential for a running testnet within a year.
Full Transcription
Hey everybody, and welcome back to another live stream here at the 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.
Thank you!
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? I will go last. Oh, you're last, okay. 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
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 kind of funny,
because everyone was coming up with names that are super serious, 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.
That's the idea. It was supposed to be fun.
Okay. I'm Daniel. I'm part of the Gemixir team, building gem 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 being 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.
The team is a bit larger, we have four members but all of us are working part time.
So like the main outtake I 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,
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 shredders believe that this will be the future of
polka dots 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 the design of jam all right 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 keep myself up to date and have further avenues of contribution in the first two milestones of the prize, such that I can keep myself up to date
and have further avenues of contribution in the future
when Jam is actually in production.
OK, 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 okay that might be a good way to kind of
come back to the ecosystem with all the kind of 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.
Yeah. So in my case, I think me and 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 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?
I mean, I came here because I was consulted about some of Jam.
What do I find interesting?
Well, the data availability thing's gonna 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 optimise.
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 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 like from that point
of view it might be attractive even if the philosophical kind of
things are not 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 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 Jam,
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 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 10 years ago,
which is 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 you 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 it's not an insurmountable task.
People who were in your position a year ago
and three years ago or two, three years ago
are now 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, 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,
and 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 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 said, 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's welcome in May 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 the Jam Toaster.
test ready for for the gem toaster and
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
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
It will be huge
Also for those of you who don't know like well, 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, okay, so what's the actual goal, right? It's 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.
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, JamPrize, 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 Polkadot 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 team and how many people is in there, maybe
like hundreds 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 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 test
net 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, 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 2 and then for instance pivot into being
In browser light client for for John
Yeah for us
elixir
It's still a question mark if we can make it for up until milestone 5. 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.
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,
the way I don't need any, 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 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 all 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.
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.
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 Polkadots,
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 PokéDot area.
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.
Presumably 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 Foundership.
So yeah, we'll see.
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 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, 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 SaaS 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 performed.
You know, block space, bandwidth, everything, rather than performed.
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 the community is 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 parachain teams?
I have a question to you.
Do you know more than the rest of us on this?
I would say that 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 it
every single time I'm talking about Jam.
There is a place for parachains and current teams.
There will be a way to migrate individual parachains
to a service that handles parachains on Jam.
Then the question is, how do we actually do it?
And this is a more
difficult topic they 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
and I think a lot of people are playing with the idea and trying to figure out
what the trade-offs are and 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 Jam,
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,
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.
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. 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, like kind of echoing what guys were talking earlier,
we know that Jam is strictly more general than what we have in Polkadot right now.
Like that general that we can take the existing Pocadot system and kind of
migrate the parachains and they're still gonna be working but the question is
like what else is possible like beyond just taking the the parachains and what
other options these this new system enables us to do for instance that do we
still have to have chains can 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 an experimental framework that's
coming from the parity team and Gavin, the Jam SDK,, 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 gonna 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 like a single token, two or three entities controlling everything.
So all of them are looking are like just
different projects trying to catch up, but all of them have the same characteristic.
Everything is centralized.
Even Ethereum layer tools, 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
wait, get away from 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 for a while and and became all sorts of things besides 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 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.
of you that comes with us, the faster we will get there.
Absolutely, this is the dream with Polkadot and now Jam compared to L2's is that we would
have to have be able to build protocols that were decentralized 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 Pokedot 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 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 possible
gonna be possible on Jam and we're 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 that never went to pull requests.
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 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, you know, sensor, whatever.
Okay, I'm going to take this.
I strongly believe that one of the main use cases for Jam 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, five million people, only a
few countries are big enough to build its own infrastructure.
And even if they be like like I'm from Brazil.
In Brazil, there are 200 million people there.
And even Brazil 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 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 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 only sovereign solution
for countries is Polkadot and Jam.
Countries is Polkadot and Jam.
Hello.
Most of the projects in the implementations 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 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 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% of the teams that are listed there have some
contact method. So if you want to specifically join one 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 shout-out there 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 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
Enjoy any team, then build your own team and go for it.
for it.
Yeah, back to, like, I want to catch up with Constantino's 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 addressed so far, as far as I 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.
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.
JamPrize 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're 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. Thehip 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 at least we
have OpenGov 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's 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 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 highest authority.
And also we are building an infrastructure, right?
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.
All right.
We're on time.
But I think there was one more question that's address,
and then we wrap it up.
Yeah.
Thank you, everyone everyone for the speakers.
It has been a very interesting discussion so far.
Still around this, you know, 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 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 ten 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 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 the 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 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 time working into it,
we all know that there are some decisions that need 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 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-share 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.
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 can only 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 that 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'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 don't 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 Polkadot.
And I think it probably already is for PokéDoc.
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. 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 limited to storing the history of just one chain, right?
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 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 or 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 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
...service during the history of everything ever.
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.
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 but Jam relaxes this
requirement and gives you a control over this right. So if you want to have
everything on chain well 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 data lake,
but then, yeah, you have this issue of, okay,
I need to incentivize someone else to store that data, right?
and pay accordingly.
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 coreplay, 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, 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, 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,
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 bind 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 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 who's gonna 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 core play, like, what would be the kind of proposed structure
for core play, so you can probably, like, look up the recording,
I'm not going to be kind of repeating that.
And also to address the second thing about like why this thing cannot be just
run on core VM. I mean it's it's a process right and the first and the kind
of from the implementation point of view the simpler 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.
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 collater 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 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 and as modular as possible. And on top of that, wasted work if we do it on
the relay chain, jump chain or whatever as a 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? Would Jam set standards? What do you think about that would it become maybe a industry-wide standard in future
I mean it's a question that essentially forces us to make a bet and all of us are
working on it because we think it has a chance. Is 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 and 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 if you remember if Solidity is what they wanted
They will have it if high throughput and low prices 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
that might target different niches and different audiences and what I can say
niches and different audiences and
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.
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 hope.
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?
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.
the cave and it's really possible but from at least my perspective so if you
And it's really possible.
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 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 I my guess it is that we
are going to have at least eight good implementations of GEM, 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.
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, 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 and 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 ELS and everything
and I'm excited that we're slowly getting there.
So, yeah, I kind of echo what my predecessor said. And, like, I also agree that we will,
we are yet to see, like, how many teams,
and it's going to be easier and easier to assess
because from my personal kind of 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 had 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 4 is like production ready, like Polkadot in terms of performance. performance and milestone 5 is being audited by someone that will audit and
say okay this is really a safe software to run and you you can run anywhere so
this is these are the five milestones so basically milestone I don't know how
much milestone 5 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, 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 the 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 milestones,
they also have a lot of locked dots given to them as a part of the prize.
And generally, 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 for your projects so
basically you have that 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 has the he or she has the the knowledge to build it and has the
reputation so you build the reputation and then with this reputation you can
like 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 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 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 JAM 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.
is just a salary like you're getting a salary from the fellowship yeah and and
yeah didn't mean only monetary like incentives but also like what it 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 also have diversification on the client side right what's the benefit of
having multiple no no 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 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 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 Bitcoin fell back into this social consensus where people said,
OK, 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 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 want to say like MEV-related stuff, but perhaps, right? then we can have implementations that give you some additional features.
I don't want to 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 engaging different communities. Because
we all know that each programming language has its own community. And we are building
in Elixir, so probably we will 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 our data's
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 gonna 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 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 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 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 is 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 PVA, 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 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 jam running is
something that is, it might be interested if some people are like, like
you, if you like interface and visuals, definitely something that it's 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 like a converter between JSON and Jamcodec, I think.
And then Grey Matter team is actually maintaining a whole
documentation website. I think it's jam
I am right and there are there is documentation there is some kind of excerpts from from the gray paper and also links to other resources
something that was mentioned on one of the jump implementers 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 prizes for the teams to demonstrate the history of
their commits and you know, but there's nothing like weird going on there that it's coming
from like the authors and you know, 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
asset hub or one of the system parachains with the commit hash.
So we have our history, 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 user experience in the future?
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 a issue with
the usability, we need to improve it, but Jam is a lower level it's just like we are
we are building the 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 is 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.
And now you have like, no wallets, subwallets,
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 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 POCO.hub and 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 like a good UX
products on Jam because there is you know a little bit more moving parts there, yet still it's
like 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 congratulations again it's the last day
of Academy and the last literally the last piece of your mandate here.
So go rest now and have a good evening.
