Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
PBA Special: JAM with the Builders
Recorded: April 9, 2025 Duration: 1:34:50Space Recording
Short Summary
The Jam protocol is gaining momentum with 38 teams actively developing implementations across various programming languages, showcasing a trend towards decentralized expertise and collaboration in the blockchain space. Key discussions highlight the importance of community engagement, innovative project launches, and the potential for Jam to redefine infrastructure for sovereign technology solutions.
Full Transcription
Academy in Lucerne. We have a wonderful audience with us today.
And we've arrived at the part of the Academy where we dive deep on jam. We have a wonderful
panel with us today. We're going to throw it over to Kian Paimani to introduce the panel and get
going. Enjoy. All right. Thanks, everyone. For those who are watching us in the classroom,
most of the people in the panel, you know them,
but for the live audience, let's start with a round of everyone
introducing themselves, telling which team they're part of,
and how they got into Jam.
So I'll hand it over to Tomic for the first.
And what about you?
Oh, you're last, okay.
Also, I have a teammate to represent my team, so.
Okay.
Hello, everyone, my name is Tomek.
I'm part of the company called Fluffy Labs,
and we've decided around eight months ago
to implement Jam in TypeScript,
and the implementation is called TypeBerry.
Along the way, one of our goals was also
to improve the development experience of other Jam
teams, so we are also focused on building
Jam-related tooling.
Can you ask yourself why Fluffy Labs 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 these mathematical structures, kind of labs and something like that.
Formal specified.
Fluffy Labs can also be like Fluffy Labrador. This is why on our sticker we just have a dog.
That's the idea. 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 I stop, no, can I do it? Everything is right? I also share some content about Jam on Twitter so people can also understand what we are 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
I'm Maciej. I'm part of the grey matter team and we're also building an elixir based
Jam implementation, but in our case team is a bit larger
We have four members, but all of us are working part-time
So like the main outtake one I 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 share this,
believe that this will be the future of Polkadot.
I think it will provide further abstractions,
stuff we can build and open many different avenues that were not possible before.
Hi, I'm Alistair, lead scientist at the Web3 Foundation, and I'm mostly just giving theory support for the design of Jam.
All right, thanks everyone. And for those of you who don't know, I'm Kian, I'm also part of Grey Matter, and as mentioned, working part-time on Jam.
My main motivation in doing so is also
to gain knowledge of the protocol, especially
in the first two milestones of the price,
such that I can keep myself up to date
and have further avenues of contribution in the future
when Jam is actually in production.
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 like because I found this really interesting. I used to work at Parity, I worked on Polkadot in the past, then I had a short break, and then I was like, 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
full-time on
this and yeah I guess I guess that's it yeah you can make just to change the
do order yeah so in my case I think me and 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 was going
through the gray paper of all the different stuff in it. I think this is
like the main reason why and 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.
Alistair, do you also want to comment on maybe what do you find interesting about Jam?
That's a different question than you're asking.
Why are you here?
I mean, I came here because I was consulted about some of Jam.
What do I find interesting?
Well, the data availability thing is going to be fun.
I can't wait to see how people are going to use that.
What else?
I mean, so if you ask me the question, what is Jam 4?
I would think that aside from the generalization
of what's going on in Polkadot,
actually, we got to the point where Polkadot wasn't comprehensible to one person anymore.
Part of the motivation behind the gray paper was just,
let's try and have a single protocol that we can spec for at least part of Polkadot.
And if we can understand it, then it's
going to be maybe easier to optimize.
And as a result, Jam is aiming for a much higher performance
than we can get out of Polkadot today.
It's an ambitious protocol.
And yeah, I look forward to seeing you.
OK. Yeah, I look forward to seeing. Okay.
Sorry, I wanted to add something.
Like, purely from the engineering point of view,
if you look at the project, at the jump project,
it's like you have a complete specification of the protocol.
It's still evolving, sure, but it's meant to be complete.
And you have a completely
greenfield project, you can pick whatever language you want, because they are split
into many language sets, and you will eventually, you can also take part in the Jam Prize contest,
let's call it, and be rewarded for that. So I think from that point of view,
it might be attractive even if the philosophical kind of things
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 Jam, because even if we don't finish and if
we don't get the prize, we will get so much knowledge and so much connections and working with guys, with the best guys like you and all the other Jam implementers is something so valuable.
Working close to Gav and building this team together is so much valuable because after it, there will be a lot of things to build on top of Jam.
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 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 GEM, 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. 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 like it's for me, at least, is a long term journey.
It's not a a 100 meters race.
It's a marathon, and we are just in the first kilometer of 42.
So there are still a lot of roads to run,
and everybody is still very welcome to join the boat.
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 this is one 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.
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 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 is welcome in May.
We're going to have our Jam Experience event.
And we're going to try to launch the test net by then.
Let's see if it's possible or not.
But yeah, we are working hard to make at least a few
implementations test ready for the Jam Toaster.
And coincidentally, the Jam Toaster,
which is a data center that is being built to run the test net
or the pre-test net,
let's say.
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, okay, so what's the actual goal, right?
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 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 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 polka dot
fellowship right now is to hedge against any particular company being the
development bottleneck or the knowledge bottleneck of the existing Polkadot
and Jam with this prize and like this 40-something team and how many people is in that 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 say let's talk about the future a little bit
where each implementer team wishes to see Jam and their clients in the short and midterm,
like within the next one year.
What do you want to achieve and see, both in your team and Jam in general?
So let me start from Jam.
I really hope that within a year we will have a running testnet of Jam,
and I really think this is achievable.
And for my team, well, we didn't pick the fastest language to implement Jam in,
so it might be quite hard for us to go beyond milestone 3,
which is Kusama level performance. However, since recently there are different paths that we might take
that, for instance, don't require us to implement in our language of choice
to implement the high-performance PVM recompiler to the native code
because most likely that would be the kind of prohibiting factor for us.
So yeah, we have ambitions to go kind of beyond milestone 2.
But I would be happy if we reach milestone 2
and then, for instance, pivot into being in-browser light
client for Jam.
Yeah, for us, Elixir, it's still a question mark if we can make it for up until
milestone five. I'm a believer, but let's see how it goes. And there's always this like
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 bug less 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 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 we with other
people this is what I love to do and 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, for sure.
From my point of view, it's more a question of
what features can we get into version of Jam
and what won't make it.
I mean, so Tenda, right, talked about DKGs
the week before last, right?
If we get Threshold Crypto into Jam,
we can save the amount of work validators have to do in ELLs by 40%.
We can have 40% lower spec for validators, 40% more cores-ish.
Something like that. A big number.
But I don't know if that will make version 1.
And probably you guys don't want it to make version 1 because you'll have to do extra work.
I have a follow-up actually for you, Alistair.
You mentioned version 1.
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.
fork on Polkadot like it would be on Bitcoin. It's not any different.
That's very much, that's still a hard fork on Polkadot like it would be on Bitcoin.
It's not any different.
So, but yes, Jam will have, Jam's hard forks will be new, a little bit new in the Polkadot area.
And yes, I don't know how it's going to work.
The fellowship will be more involved.
They're already pretty involved in 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, or I have not misheard it.
I don't know.
I'm still thinking that there's no real urgency
with quantum-resistant crypto,
but perhaps the important thing is not that we adopt it,
but that we have a fork ready to go.
So we're looking at, right now, all the primitives in Polkadot
and seeing what we can make post-quantum.
In some cases, it's easy.
We just switch out our elliptic curve signatures
with lattice signatures, now already standardized.
There's some options, but it's pretty clear what you do.
For other things, like the BRFs we're
using in ELVES and Sassafras, it's not so obvious
that we can do this with post-quantum crypto at all,
or 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.
whether we should deploy them on something like Kusama first.
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.
There is no way to make performant and quantum resistant to decrease performance somehow.
There's no way to make performance and quantum-resistant at the same time.
There are some protocols you can switch out
with things that are actually fast.
Okay, so it's like you want to be more relying
on protocols that just use hashes,
and those protocols are already fast,
but maybe there's a bandwidth trade-off.
And the bandwidth becomes interesting. Like if I have to do 100 kilobytes snark
for my ring VRF that I used to put on the jam chain,
maybe that should move to a service.
We do sass for us partly on a service and things like that.
But it wouldn't be slower.
The main slower things, things like signatures,
get slower and bigger. Well, actually, 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 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
they are more... I think there's gonna 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 there's
not I don't expect there's gonna be a lot of contention regarding oh yeah this
feature is not something that we want because it's it's the community split
about it the likelihood of an upgrade in Jam which requires 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?
One 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 the 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.
This is important, I want to emphasize it every single time I'm talking about Jam.
important I want to emphasize that every single time I'm talking about Jam there is a place for
There is a place for parachains and current teams.
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 app,
like fellowship will be involved,
maybe governments will be involved.
At this point, it's hard to say.
Yeah, so the first plan, right,
is we build a core chain service that's capable of running parachains on Jam
and you build the Clayton stuff and existing nodes running probably cumulus as it is with
your parachain built on frame will just be able to work.
Well, have the code so that's just able to work.
Then yes, how do we migrate?
That's a different and somewhat fun question.
But the first thing is to make the logic make sense.
Yeah, I can also build a little bit of much his 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 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 Polkadot 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 jam transition happen and maybe it will shed some light here and there. Yeah worth noting like a lot of the upgrades
that are coming to Polkadot in rest of this year are moving a lot of things out
of the relay chain into one of the system chains called Asset Hub such that
we are not only improving a few other aspects of the protocol and user
experience and developer experience in general but also it's a preparation for Jam.
So we're already trying to, you know, little by little move things out of the relay chain
so it's as empty as possible so it can be replaced by Jam in an easy way.
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.
Too open to start.
So again, maybe from my purely engineering perspective,
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. Like
that general that we can take the existing Polkadot 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 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 an 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 to Ethereum,
they are all companies centralized with like 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, 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 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 with for everyone without any central control
entity and we have open golf we have this chain being built we have the
greatest amount of talent doing it and we are just trying to convince more
greatest
amount of talent doing it and
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 polka dot was proposed quite many years ago at this point and it was one
of the first large-scale sharded blockchains um 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 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 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?
If you want to know, like, what are the key inspirations for Jam for moving moving beyond parachains, was this core play idea
that the Gav had.
There's still a branch of the Polkadot Fellows RFC repo that 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 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 let's I will walk around now and hand over the mic for
anyone who wants to ask questions from the other panelists
thanks uh constantinos i will refer back to the thing you said um about the polka dot 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 gonna take this. I strongly believe that one of the main use cases for GEM 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 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 200 million people there.
And even Brazil is not catching up.
You can't catch up with Amazon infrastructure or Google infrastructure.
So in the end, all these small countries will have to trust another big country like China or US to host their infrastructure.
If these countries start to use blockchain or GEM as their own infrastructure,
they don't 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 trusting Ethereum,
they would trust the two centralized stakers of Ethereum that are hosted in the US.
So in the end, these countries won't be sovereign.
So the only sovereign solution for countries is Polkadot and Jam.
Hello.
Most of the projects in the implementation today are not like open and like not something that we can snoop and everything.
Let's say that I am someone that is finishing an intensive course of two and a half weeks where we learned a lot about Rust and a lot of nice stuff.
How can, how could I contact one of your, one of the teams, maybe try to contribute somehow
in this case?
I don't have a full answer for that, but I can add some extra tidbits that might help.
So if you go on the grey paper page, I mean, step one is after the PPA, sit down with the
grey 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 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 accounts there message them I think
there's like 40 or 50 percent of the teams that are listed there have some
contact method so if you want to specifically join one of the current
teams this is the way and or you know interact with some of your students from
here or other people and start your own team.
A lot of different options. This is like a partial answer.
Yeah, thanks. So you can always join Elements and on the website that Maciej mentioned there are also
links to the Elements 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 general about Jam.
And then you can do a shout out there.
And all of the Jam implementers are there.
And usually, at least maybe not all of them,
but some of them have their own channels which are related to their own implementation that you will most likely get invited to.
And then you can take it from there because, yeah, it's not,
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'll follow up.
If you can join any team, just raise a message.
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 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 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.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, because the token holder will probably understand nothing about these upgrades.
So should they have a say on this?
And 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 I understand.
It's a difficult question.
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 jam chain because it will not be upgradable. But hard forks are technically possible in the future and fellowship will still be involved.
So my opinion is that it might make fellowship more important and relevant.
Especially because fellowship and jam are not totally separated.
JamPrice has some mentions and incentives that if you start building those implementations,
you might potentially have some benefits and speed tracks to get into the fellowship.
So they're essentially trying to funnel all those experts building those Jam implementations into the fellowship,
hopefully creating this DAO that can vote and create the future of the protocol.
And the fellowship is then kind of contracted by governance.
There are proposals and they are essentially obligated to listen to some of the votes coming in from governance.
But this is an opinion of one person. I think many different people will have different takes on the subject.
But this is an opinion of one person. I think many different people will have different takes on the subject.
Yes, we don't know. The situation will evolve.
So we don't know if there will be token votes that will be important or not.
For sure, yeah, the fellowship will be more important.
The diversity in implementation, maybe that moves us a little bit closer to the Ethereum's thing with its downsides of
having to wait five years for one team
to do this particular thing. I presume we'll try and be faster than that. But
yeah, we don't know. Fellowship will be important, maybe that we vote.
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 open golf for something
No other change has beside let's say Cardano or whatever chain has some some kind of governance
There's no governance at all so token holders anywhere though. Don't 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 hots 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 Jum.
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, like, I would say, highest authority.
highest authority. And also we're building an infrastructure, right? So it's the fact that the
And also, we're building an infrastructure, right?
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.
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
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, you know,
I'm 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 futures because
I'm assuming that for these members you're also building
Jam and you would like to also be able to you know carve the futures of Jam in the next let's say five or 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 price, and the gem price will be paid in DOT, and the DOT price will be paid in locked dot. So there will be a lot of dots in the hands of gem implementers locked,
so there will be a lot of voting power on the hands of the gem implementers.
So the idea of creating the gem DAO was,
okay, so we are going to have a lot of 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 taken and we need 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 gemdao 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 proper calls,
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 errors or 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 in our 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,
then it's possible that some node that was sort of following this before,
and it doesn't update in 24 hours, then you lose the data.
It's exactly the same problem.
Now, what we hope, but with Jam, we're trying to move beyond chains,
so it will be more like the 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 lines 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 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.
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 to more to the sort of
like client thing with the Erasure Coding that Ethereum have 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.
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 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 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 will be crazy.
And also on top of that, something like polka.hub will probably still be present in Jam.
If you just want to have a smart contract, someone else will do the incentivization protocol on something like
polka.hub to run the collator in jam and you can just forget about it and do a smart contract there
like this will be an option and it seems like this is what you want and this will be there you just
don't want to run a parachain then do this so So I think the important thing to note
here is that the requirement
is still there but Jam relaxes
this requirement and gives
you a control over this. So if you
want to have everything on chain
well yes but then you are constrained with
whatever you can accumulate and you have to pay for
this or you can move on the other side
of the spectrum and have everything in the
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.
What are the QN functionalities or features or needs that users have that are not possible with Polkadot and we need to move the job?
I mean, the first one that will come to mind, and this is something I don't know that much about but the idea with coreplay is that you can have as far as I understand some
kind of an unbounded execution that will eventually slowly execute on chain
over the blocks and and some of the promises where there 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...
Some of this was built into Polkadot.
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 buying stuff we still have like this core VM the will be on the service. But my question is, Jam will be running under the runtime, right?
We still will have a grand point.
We still will have like this core VM,
the general virtual machine,
which is gonna be running.
Why we can't have governance there?
Why we need to bring on the separate service
and actually bring all the security assumption
that was just talked about, right?
That 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, it's not like inherently in Jam
and you just deploy something and it runs.
Like it's a service.
The service requires the core time
and someone has to provide that core time
to execute your service.
And how, like who's going to be the person
who actually provides that core time
and executes that service, that's not defined.
The validators will obviously make sure that it was run correctly,
but you still need to figure out, 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 like what would be the kind of proposed structure
for for for core play so you can probably like look up the recording I'm
not gonna be kind of repeating that and and also to address the second thing
about like why this thing cannot be just run on core VM I mean it's it's a
process right and the first and the kind of from the implementation
point of view, the simplest way forward is, OK,
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?
just put everything on it, as we are going to do with Jam.
So it's clear we need to migrate Polkadot
onto Asset away from the Relay Chain in order
to switch to Jam.
But why don't we put everything on the Relay Chain
to start with?
I mean, aside from the fact it's not really scalable.
And yes, this, well, because we want to make...
One of the chief reasons behind Jam
was to make the central protocol of Jam,
or indeed of Polkadot moving stuff off the relay chain,
was to make it comprehensible.
You know, we want to make things modular.
We weren't really having that if everything's on the relay.
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 AssetHub migration coming up, I'm certainly very invested in making sure.
So the answer is we need a diverse collater set.
We need lots of full nodes of AssetHub 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.
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 jam chain
or whatever as core part of it hello so during the session you mentioned how much the jam will
influence the polka dot 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 it?
Would it become maybe an industry-wide standard in future?
I mean, it's a question that essentially forces us to make a bet.
All of us are working on it because we think it has a chance.
Is it the way I would like to phrase it?
At least that's how I think about it.
I think we noticed in the past,
especially with the Polkadot hub and asset hub migration and all of that,
people like doing stuff in Solidity. So we are giving them smart contracts in 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 Solidity is what they want, 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.
Maybe Polkadot has issues with user-friendliness
of deploying stuff.
And it's really important that people
start building that for Java 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 jam note I mean maybe it's
just let's try let's deliver just the milestone X but I want to know do you have any idea of
teams that are here to deliver the thing yeah it's really hard to answer this because it's an open protocol.
So there might be like hundreds of teams working in the cave and it's really possible.
But from at least my perspective, so if you go to the Gray Paper website, you have 38 teams that officially announced that they
are working on it.
And from those, you see a smaller group, let's say 20 or 25, they are interacting in the
chat and asking questions and making some kind of comments.
So you see that they are active.
And we have these Jam meetups that we are organizing
that the teams that are more eager to go there and stay together
and coordinate in some way,
like teams that are participating of the Jam DAO,
something around maybe 15, 20.
And from those, probably most of them will get up until at least milestone three.
Of course, going up to milestone five is very much dependent on the next steps.
So I would say after milestone one and two, we'll be able to answer this question more safely.
But my guess is that we are going
to have at least eight good implementations of Jam,
which is far more than any other protocol ever.
This is my guess.
If we can make a bet now and after five years,
we can get a prize for those who get the right answer.
But it's just a guess.
Well, people are saying that you still have time to get in.
I think you probably still have time to reach milestone five
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 or 5?
Because that might determine who gets in.
We still, like, I'm still worried that the gray paper doesn't really fully specify consensus
and everything, and no one is building that yet.
I agree. It will have to.
But I think the more people, the further we go in the implementations, the more questions will arise in all those chats.
And we will slowly specify it because I think it was already happening in the previous milestones.
People were asking a bunch of questions 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 ELVs 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 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 one to milestone two is probably
the hardest, I would say.
And after milestone two, there is still like a slight jump into Milestone 3,
which is getting like a decent performance.
But after that, I think when you see a team reaching Milestone
2, then it means that they are like 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.
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 great paper clarify,
and how many does not?
OK, 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.
And Milestone 5 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 save some feedback.
You have to change, you have to follow all the audit rules
until you get it.
But three and four are performance and one and two,
one is just block importing and two is full node even if
it's poorly performant. Thank you very much. The second question I have is there
is an incentive for people to build various implementations of the protocol
now. What are the incentives to keep having like a diversified ecosystem after
the prices and everything is gone in a sense right
actually i can briefly answer that so the pro the part of the jam prize is also like a promise of
uh 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 built 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 OpenGov
to improve the chain and get some monetary funding for your projects.
So basically you have all the knowledge that very few people have to build other stuff on top of blockchain,
on top of Jam and Polkadot. So you have the power to propose things that people will see,
oh this is a good project and he or she has the knowledge to build it,
and has the reputation.
So you build the reputation, and then with this reputation,
you can get funding for whatever you want.
So basically, after you build Jam,
you'll be probably in a good position
to ask for funding for anything that you want to build after.
Yeah, to follow up on what Kian said, I think the rules say that for every milestone that
you submit, one of the members of your team can be proposed for rank three of the fellowship.
And also what Kian said as well, regarding the incentive there, I would kind of expand
on this because I heard it mentioned today and yesterday.
It's like being in a fellowship.
It's not like a club where they 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 a couple of implementations
out of all of them
that are there.
And maybe just to be clear,
the mystical incentives in the fellowship
is just a salary.
Like you're getting a salary from the fellowship.
Yeah, and yeah, I didn't mean only monetary 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 also have diversification on the client side right what's the benefit of having multiple
clients no no no what are the incentives like why people would use like the x client and not y client
actual validators running the hardware yes exactly like 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 of them was reaching like
the 51% threshold. And what people did, they actually withdrew money from that mining pool,
people did, they actually withdrew money from that mining pool, even though it was paying
the most. So Bitcoin fall back into this social consensus where people said, okay, we don't
want this mining pool to have 51% of the hashing power. So we are withdrawing our hashing
power from that pool and we are moving it to someplace else to make sure that it's maybe
not super evenly distributed,
but definitely to avoid the situation where we have one implementation running the entire
network.
If there is a bug there or something happens, then we are screwed, right?
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. 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,
in some particular mode of operation, let's say.
Like some might be more optimized
for running on Apple Silicon, for instance, and some other 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?
So it's also a path for the Jam implementers to innovate here and propose some features that are unique to their implementation.
I have just another complementary thing is that because each implementation is done in different programming languages,
each implementation is engaging different communities.
Because we all know that each programming language has its own community and
We are building in elixir. So probably we'll engage more elixir developers to build on top of it and
Because of that after some time
each team will
Want to keep our 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'd point out the obvious again,
but just because 95% of validators are running this implementation right now
because it's more performance and they get more money,
doesn't mean that in two years' time it's going to be the same.
Hello, I'm P Paulito. Earlier today, Tomic shared that his team created a tool for reading the 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 the one that I saw, there are not so many, so there's plenty room for innovation in this side, I think.
I speak for myself, for our team.
We are so much occupied building Jam that we don't want to waste time, at least right now, with other stuff.
And we are still a small team, just two people.
So depending on the team, you can spend more time on tooling and things like that.
But as time evolves and you complete the milestones,
you can increase the team size.
You can afford to pay for other developers
to join the team and build other stuff.
But up until now, I saw that the PVM run it.
I think Fluff Labs is doing amazing work with this.
And there 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 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 Jam
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 that the chain, all the nodes running,
what are the nodes, what they are doing,
and making some visuals of the gem running
is something that it might be interested if some people
are 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.
Yesterday Gav showed the Jamtop tool that he developed or someone from his team. Jamduna team has like a
converter between JSON and Jamcodec I think.
And then the Grey Matter team is actually maintaining a whole
documentation website. I think it's Jamcha.
Jamchain. 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 JEM implementers
calls is this kind of search engine
that would be able to index all of the messages from element
and make them searchableable because I think for many
people the search on the element doesn't really work that well
I can also add something small here one of the requirements of the Jam prize is
for the teams to demonstrate the history of their commits and you know 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
the 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 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 how do Jam or let's say the Jam era going to address this issue?
What do you envision for Polkadot in terms of user experience in the future?
I think it's something that is not in the scope of Jam.
It's something completely out of scope of Jam.
It's something completely out of scope of Jam.
I agree that there's an issue with the usability.
We need to improve it.
But Jam is a lower level.
It's just like we are building the road.
So how the cars that will pass on top of it and how they will manage to the traffic and
what colors the cars will be doesn't matter for JEM at least. What we know is that of course
we have a better road with very soft let's say asphalt that you can run on top of it.
So probably the other layers built on top of it will be promising,
but nothing that is guaranteed better experience for developers.
But this is something that needs to be built in parallel.
Yeah, I completely agree.
And I think it's just the answer to that is not Jam, it's the work
being currently done on Polkadot Hub,
all around it, Polkadot
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, SubWallet, 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 so add maybe a tiny bit to that i definitely agree the wallet situation has gotten much better
there are big improvements more work to be done. But for instance, by having Ethereum smart contracts on on Polkadot Hub, we can start
benefiting from Ethereum tooling, Ethereum IDEs and stuff like that. And I don't know how much
work you all have done on like 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 that you start you start fresh and you can start building this stuff and I think
it it also depends on you know 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.
