Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Cardano's Roadmap: A Tier List
Recorded: March 27, 2025 Duration: 1:36:59Space Recording
Short Summary
In a recent discussion, key figures from the Cardano Foundation explored the future of Cardano's ecosystem, emphasizing the importance of partnerships, innovative solutions like Hydra and Leios, and the need for improved scalability and user experience. The conversation highlighted various growth opportunities and potential funding initiatives aimed at enhancing the platform's capabilities and attracting new users.
Full Transcription
So hello everybody and welcome to today's live stream.
I'm joined by Giorgio Gianetti, the CTO of Cardano Foundation,
Ketors, the Technical Director of Cardano Foundation,
and Sebastian, the founder of DC Spark and Pima.
My name is Jacob, I'm the Social Media Manager here at CF,
and today we're going to do a little tier list of cardano's product roadmap you want to tell us
more about that georgio yes absolutely so this was uh this idea originated in japan in tokyo
a few weeks ago where i was with yuta and seiba and yuta asked us to kind of rank the the items
in the in the the roadmap for the for the budget and we came up
with the this idea of the tier list to make it a bit more fun and engaging and since then i think
many more people have contributed to this tier list and uh yeah we thought it would be fun to
redo this format in a more thought-through way not just on the spot and I thought who better than Seba and
Matthias to invite to do this. So I just want to disclaim that all of our views are just ours and
you might disagree with us. This should not be, it's not an endorsement or like a disavowment of anything so it's just helping educate d-reps
on the innovations and usually engineers are not very good at business stuff so maybe it's
just a technical angle um yeah i hope you you have fun and you come up with your tire list as well
Yeah, absolutely. Let's get into it.
yeah absolutely let's get into it here let's put this uh stream list
Here, let's put this stream list.
Yes. Let's jump right into it.
I vibe code this afternoon,
this theory so I hope it's not buggy.
In case it is, I have a backup spreadsheet.
So let's go item by item.
So we could quickly explain what each item is.
Maybe we can take turns, the three of us,
and then we can give our own thoughts
on which rank this item would live in.
So the first one is state machine contract environment.
And this is a piece on the Hydra protocol.
I don't know, maybe, matthias you want to start you are a hydra uh person how can i say you worked on hydra how do you see this piece of
uh foundational research um well first i don't quite see what specific to Hydra, to be honest. And I mean, we have got state machine abstractions in the past on Cardano.
And they have proven to be quite more expensive in the end than the alternative,
because they are usually not first class citizen in terms of support.
So I think there is room for doing that better
but like if by state machine contract environment we kind of include more generic stuff like
um you know an actual new ways of maybe writing smart contract for cardano which will be you know
reusing the utxo in a in a better way or leveraging that better
with a completely different VM, possibly.
I think that could be quite high on the list
because that's both something which is quite tangible
and could solve really interesting problems in terms of compositions
and so on for the smart contract space.
So at least BTO for me.
Yeah, if I can add to that as well,
this is something that we've also looked into.
So as Katal's mentioned, there's a few different projects
that have tried this in various ways.
One of the reasons it's a bit difficult is because in Ike and Pluys, you have to carry over states
manually.
So these become a bit hard to write by hand.
And so people wanted to have frameworks
to handle these state machines with less programmer effort.
The problem is, of course, this layer of abstraction
usually end up adding cost.
This was part of our motivation for building StarStream,
which you might have heard of, which is the new VM we're building,
that's UTXO-based, where we model these state machines as coroutines,
specifically try and solve this problem.
And part of the reason this is related to Hydra
is that if you do something like StarStream and add it to the Cardano layer one,
then Hydra automatically gets it because Hydra is kind of an isomorphic layer two. That is to say,
it reuses the Cardano environment. So there are some connections in there. Now, I think this
originally came, this proposal came independently from the work we're doing. I think this came originally from some of the more Hydra-focused people.
But I think it generally shows that there's multiple different teams interested in trying to make the estate machine work better.
Of course, then the question becomes, which approach do we want to prioritize?
And I think that's maybe the point that's less expanded upon in this uh budget
item therefore i think conceptually it's a high party because a lot of people independently have
said they wanted this so clearly there's a large demand um it's just that you know we from this
budget item is a bit more vague it's more of like an exploratory side in the way it's worded.
So I'd say like maybe B or C because of that.
All right.
Let's park it in B and then we see.
I don't want everything in A or everything in one bucket
so we can discuss it later.
I would agree on B. And let's, there's maybe five more items related to
Hydra. So there's maybe we can take all of them at once and be done with Hydra. So there's Hydra.
This is part of the TSC and the roadmap development, Hydra development.
This is part of the TSC and the roadmap development, Hydra development.
So this is clearly something important. I don't know what's missing. So I can go ahead and also
put it in the B tier. It's an important initiative, but I don't know what's the definition of that here.
Yeah, I think something that generally applies to all the Hydra-related
proposals is that Hydra at this point has been a project ongoing for a few years.
And as you know, there's things that have been built with Hydra so far, like the Doom
on Hydra demo that was built. And there's some people that want to do more stuff with Hydra.
Like I know there's people trying to work on DEXs and these kinds of things.
That being said, I believe we're kind of in a year of productization for Hydra,
where there's been enough R&D work that we have kind of an idea of the concept and how it works.
And our focus now should be trying to, as an ecosystem, productize this if we think it's worth productizing.
One thing I think is missing from the Hydra-related budget proposals is any sense of KPI or end
result.
As an RDI item that's been in the works for a few years, I would like to see, okay, if
we have another year of Hydra research work, this is what we expect as the end result.
And I think some of these proposals are a bit more on the research side.
That's to say like oh like
it would be cool if we had this and although i can definitely understand that i would rather come at
it from the inverse direction which is like there's this product that we think could be built with
hydra within a year and maybe it requires this extra tech to build um and so for the hydro related
stuff i would like would like whoever's focusing
on those efforts to maybe try and propose a more concrete product
version of what these roadmap eyes will bring to the community,
because otherwise it's a bit hard to think about the impact
these will have as a budget item.
But this will probably fall outside of the roadmap.
It would be more builders and catalyst type of innovation, right?
I build a DEX with Hydra.
I build a video game with Hydra.
Yeah, it's less about funding product ideas in the roadmap itself.
It's about laying out concrete products that could be built
if we spend another year of research on this, right?
Because we want to convince the community, like, hey,
this money is being spent because it will enable these new things that require another year of research on this, right? Because we want to convince the community like, hey, this money is being spent
because it will enable these new things
that require another year of work.
Exactly.
I mean, if you want to use cases,
you need sometimes, you know,
necessary updates to the existing stack to enable this.
And given that today Hydra is literally
the only scalability solution that we have
that is usable right now.
To me, it's a top priority.
People started using it.
It took quite a while in the end to get adoption on the Hydra space.
And now we're seeing more and more people building on that.
So it's it's time to kind of use that momentum and and, you know,
do something with that solution, you know, scale it in terms of its features, its usability.
And so that's a top priority, if not an immediate imperative.
Because we won't have another change to get people on board to Hydra.
If we put some effort into that in five years, that's too late.
So it's right now, and that will help for other L2 solutions
that are coming after that.
Okay.
So do we agree and put it in A tier
with the caveat that is not research anymore,
but it's just getting things done
and make it to use?
Would it be fair?
Yeah.
Yeah, great.
There's a few more either stuff.
A few more Hydra stuff.
One is, where is it?
Optimization tools.
Optimization tools.
This is about making the family of Hydra,
smooth operation, Hydra network,
locking collateral funds.
Is this something that goes in the direction
of what we discussed?
It's the exact same thing as what we discussed.
I mean, Hydro Development and that,
to me, there is no difference.
And I'm not sure what are two different items,
probably because they were proposed by two different groups.
But there's also the same thing.
There's also this auditing tool,
I guess, to provide more transparency.
Shall we also cluster it in the top uh a a tier
or is it we don't like this auditing we like the anonymity of things obfuscation i don't
quite see also what is specific to hydra here or like what, what exactly do we call auditing tools here?
I think the TLDR is that the Hydra channels are not very, as today, they're not very easy to understand
what happens inside.
And the auditing tool would give you this view
on what happens, you know, when everything is reconciliated,
kind of an explorer for Hydra if you want.
That's my L5 understanding.
Well, I would argue that's a feature indeed
that you can't necessarily see what's happening in the head.
And it sounds also very application-specific. I don't think this has its room on a core item roadmap.
Yeah, I have the same feeling.
My feeling related to this is that there will probably be specific index resolutions
that will come up to try to solve this problem. related to this is that there will probably be specific indexer solutions
that will come up to try to solve this problem. It's a bit hard to make generic because how many heads will be required, how those heads will be set up when you add new heads, when you tear stuff
down, as we just mentioned, somewhat application-specific.
And so I'd probably prefer to see this come from specific business requirements
as opposed to building a generic auditing tool
and hoping it's what people need for their use case.
F, not recommended.
What do you say, Seba?
You also put F, D, C. I was thinking more C
would be if we have time.
And so what do you think, Seba?
SEBASTIAN BASTIANI- Yeah, I think for me,
yeah, most D unless they have a specific adding tool
for specific use case in mind.
SEBASTIAN BASTIANI- OK, then let's put it in D. Then we have Hydra Tail and Interhead. Who wants to explain
what Hydra Tail is? And it's a foundational research.
Well, that's kind of the point. No one can explain what it is yet. So I'd rather go for
the Interhead Hydra. At least I think it's easier to to park this one first
okay let's look at the paper on on that one um and it's an interesting one um that that is a step
that will get us closer to having something like a lightning network you know because right now we
can have heads that are fully independent we can't interconnect them and therefore we can't have a network of heads, which is
a lot more challenging when you start including things like a whole state, right?
And not just payments.
So I think at the very least we should have the inter-head effort goes into trying to
make a payment network and then see how we can expand that to a full state channel network.
It's an interesting one. So definitely important to me, but not necessarily as important as, you know, developing what we currently have and sort of trying to build on top of that. So I would say
B or C, possibly just C for now. It's cool, but no one also really said they wanted that
at this point.
So I'm like, yeah.
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA? SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENOVICIENCIA?
SEBAN RASMUSSENBAUMENCIA?
SEBAN RASMUSSENBAUMENCIA?
SEBAN RASMUSSENBAUMENCIA? SEBAN RASMUSSENBAUMENCIA? SEBAN RASMUSSENBAUMENCIA So I feel like it's a riskier bet than building use cases that just require the core Hydra as it exists.
So I prefer to focus on that before
spending work on this inter-head work.
Cool.
So Hydra Tail, Matthias, you mentioned.
Yeah, not a tail.
You don't know what it is.
Maybe Seba, you have more.
Can you, what is it?
The name suggest is a better Seba, you have more. What is it?
The name suggests is a better way of reconciliating. I said I don't know what it is because it just doesn't exist.
It's a resource problem.
But what problem is trying to solve is to have a more B2C relationship with Hydra,
where you can have a light node or a client connecting to some kind of server
in a trustless fashion to do payments with any other accounts or any other people on
this particular tail.
The head is more like a peer to peer kind of thing.
We both connect or like a small party, small group connects into a head and they can exchange
between one another.
Whereas the tail has this idea of you have some intermediary that can interconnect multiple accounts and all of that
can happen in a trustless fashion, right? And of course evil lies in the details because doing
something like that is actually quite complicated if you want it to be fully trustless and decentralized.
So yeah, my feeling on this one is that it's something that's
a bit hard to do without putting a lot of work on the zk approach the cave is
standing for zero knowledge cryptography cryptographic technique um one of the issues
around this is how will we properly zkify hydra and i think this is one of properly ZKFI Hydra.
And I think this is one of the unsolved problems
that's kind of blocking this work.
There has been some thoughts about, you know,
how do we ZKFI Plutus or can we use general approvers?
And there's been some work on like the midnight side
about how to verify like ZK proofs on Cardano smart contracts.
So there's been some different attempts at taking a stab at this, but I think they all
end up being fairly difficult to implement, to fully take advantage of the potential of
of the potential of the HydroTel protocol.
the HydroTail protocol.
That's why for StarStream, we instead tried to rethink
about the design of a ZKVM from scratch to be able
to keep the UTX to a model, but have it be able
to take advantage of these ZK techniques in a way
that's much more intuitive, because we've seen a lot
of people try different things and none of them went
that well
because they tried to mangle things to match the current design.
So I think probably the more straightforward way
to implement this kind of Hydra Tail would be
to connect ZKVM like StarStream to one of the nodes
that will make it automatically get supported in Hydra,
and then use that to power the Hydra tail protocol, as opposed to trying to implement Hydra tail on
the existing system. All that to say is I think conceptually, I think this is very important.
I think a lot of these cases that would like hydra would benefit greatly from this um i just think that the best way to do this that gives this the best bang
for our buck is not available today and will probably not be available this year um so i put
it at like f or d not because the idea is bad but i just think it's a bit too early to implement this
Not because the idea is bad, but I just
think it's a bit too early to implement this.
Yeah.
I mean, the fun part is two years ago,
I was working exactly on that, doing some simulation work
for one of the first version of that protocol
that we thought could be interesting.
And the simulation showed that, well, it
wouldn't work quite as expected.
And I think now, yes, we are kind of people are venturing,
or searchers are venturing in the lens of ZK for that,
because there isn't need for like batching,
large amount of stuff and so on.
So ZK roll-ups looks like interesting.
So it seems that, you know, in order to make progress on this area,
we kind of have to make progress first on the ZK items. And in particular, on doing that in Cardano.
So yeah, definitely agree.
Like D or F, like not recommended.
We mean like we have other problems to solve first
before we get back to this problem.
It's an interesting one,
but it's just that we don't have the tools yet
to make it work.
And so, you know, once we have like,
I don't know, good recursive snarks
and a very good XeonLH VM on Cardano,
we can rethink about that problem, I think.
But for now, there is no point putting that on the roadmap
too high.
So let's do F. We have our first F, not recommended item.
And as you said, it's not so negative.
It's just we need a few more years
before this is promoted to the higher tiers.
Yeah, hopefully not a few more years,
but yeah, there's some things to do first.
Well, that's always what you say first and then.
Yeah.
All right, moving on.
We have covered all the Hydra stuff.
We have location-based services and smart contracts.
So this is foundational research.
Yeah.
So in my opinion, a lot of this revolves around just a generic real-world asset bucket.
A lot of people want more real-world assets on Cardano.
Some of that is like concrete use cases,
you know, like wine tracking
or verifying diplomas or stable coins.
A large variety of real-world asset use cases,
you know, have a large community interest.
And real-world asset as a use case
is growing a lot as a market segment year over year.
So I definitely think more generally real-world assets are something that we should put more
interest in as a community. There's work on that happening a few different directions now. Like I
know the people at Anastasia Labs are working on some new CIPs related to that to try and have
more flexible smart contracts to handle real-world use cases. And some of that work will have to be
implanted, of course, at the eigen-smart contract level, but some of that work will have to be
ecosystem level. It's something that the explorers have to integrate and the wallets have to implement
because there's some new standards required for these. There's other people working on different approaches. So for example, like at StarStream,
we're working on the ZK side of things that can enable different real-world access that need
competition on private data. There's some sidechain like Midnight trying to tackle this.
I think as an ecosystem, there's a lot of people interested in working on this.
There's a lot of people interested in working on this.
Location-based services represent one specific subset
of the real-world assets bucket.
I feel like probably this is not the right roadmap item.
It's a bit too specific.
Rather, I would focus a bit more on what we need to get these use cases enabled,
and then put the roadmap item that enables that specifically. For example, if we believe that
the anesthesia labs work is meaningful, as I mentioned, there's work things done on the
explorers and the wallets and the tooling as an ecosystem to support these new standards and therefore like the budget should probably go toward you
know giving grants to these projects um yeah i i it's interesting because i when i read this item
i did not think about real world assets right um i thought more about uh you know proof of attendance or personhood like things that
that require geographical pinpointing a trustless way of saying okay this guy was actually there or
is in this close to this node and so and then you could build on top of it protocols to say
And so, and then you could build on top of it protocols to say, if you develop your,
if you deploy your node in Rapa Nui, right, on Easter Island, or you get more traffic
rather than if you are in Frankfurt, AWS data center.
I did not connect it to RWAs, but there might be something there.
Yeah, the connection is that for things
like traceability, a lot of the traceability
is around location of the specific node.
And a lot of real assets require government regulations
where data has to be stored or processed
in specific countries.
So for a lot of cases this
is like i looked at the technology a few years ago and and nothing convinced me uh that it was
something realistically doable um uh without you know because you know you can easily relay
information and kind of camouflage your position so So I think it would be something helpful,
but I don't know how realistic it is to develop.
Matthias, do you have any...
It's also a research item, right?
And the point of research is not to lead to a product.
The point of research is just to create knowledge.
So in that sense, right,
since we don't know how that could work,
I think that's a good research item.
This is something which clearly could enable some use cases.
So I'm a very simple man.
Anything that creates use cases, to me, is a top priority.
You know, we need use cases, and that's the thing we need the most.
We don't care about scalability if we don't have use cases, right?
Your chain can go as fast as it can.
If you don't have anyone using it, that's pointless.
So to me, anything that creates a use case
is at least an A tier.
But this particular item, I think,
was also split in two and two completely unrelated things.
In the description, we mentioned
it's for this location-based smart contract thing.
And it's also about making
sure that we have proper geographical decentralization on the network which are like two slightly
different things to me so i'm really just talking about the use case one the use case part here
and so i would say at least eight for me okay seba what would you think yeah i think that makes SEBASTIAN BASTIANIUSZAKANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANIJANI But I think conceptually, this is a good idea.
I would say B, Matthias is A. What's said by your tiebreaker here, A or B?
I would put it in B just because I'm not sure
how they plan to split it up.
But I think based off of that,
I could easily be convinced of an A.
I mean, B is an important initiative. We are not completely discounting them.
It also depends. We are not here looking at the price of the line items, right? This is a
D-reps job. So I have not looked at the Marcheda. So here's a big one, Leios.
I think this one needs the least amount of introduction
is the most known, right?
Is an upgrade of the Ouroboros protocol
to increase the throughput.
And yeah, I think this should be, it's S or A for me.
I think if we get this right,
should get our more scalable,
but what do you think about it?
It's a tricky one because as I said,
more speed without use cases is a bit pointless.
I mean, it's good for marketing, obviously.
And by the time you have too much users or too many users it's
to be too late to start thinking about scaling your system so that means you need to see that
coming and layers therefore is it top priority um i've got a hard time putting guess putting it
under s to be honest just because i don't think right now this is where we should put all our attention.
But it should be quite high.
Yeah, I was saying there...
Seba, sorry.
Yeah, from my side, I think fast finality, which is a pair of us paras is more important than throughput so keep in mind
these are two separate things one is how much data can you push through the other one is how
fast can that data be finalized i think uh the finality right now is probably more important
than the throughput for the usability of cardano um i do think le leos conceptually is a good idea and it does help with some of
these throughput or sorry these finality ideas uh because as you might know a lot of the transaction
prioritization robot items are assuming leos will go through some of the potential optimizations
on paris only work if leos goes through as you might also know
leos is a fairly big uh redesign of the core cardano or board system the court consensus
um so it's hard to
uh build other things while not being sure what happens with Leos.
Therefore, I would probably put it in either S or A
because implementing it gives us better clarity
on one of the other things that need to build.
I think Paris is more important than this,
but it helps unlock a lot of different things and gives us better clarity.
Yeah, I really see Leos as like Cardano version 3, you know, whereas Peras can be more seen as like
an overlay and a set of functionality we add on top that provides, you know, faster finality,
so that that clearly has a benefit for application that needs that today but it doesn't
fundamentally change the protocol and and the fact that you can actually implement perlas as a
complete overlay is kind of a you know testimony of that you don't need to change the core consensus
whereas layers like it's really rethinking the entire beast so it's also much more complicated
to implement and it's going to be much more
disruptive to the ecosystem. And I do think we're at a point where we do want our ecosystem
to develop. So it's not the right time now to break the ecosystem and implementing layers
is kind of going in that direction, not immediately because it's going to take time,
but I don't quite see how we get to implement layers without fundamentally changing the way
things work whereas Peras that feels like a more low-hanging fruit we can enable it if we want if
we do it right that means we can even possibly solve the problem of a data availability layer
because we're going to need that for Peras transferring all the voting certificates that
are needed which means that you know Mithril can benefit from that,
Midgard can benefit from that, and possibly other solutions.
So Peraz definitely, to me, could be S tier.
And Layos, it's really like,
hey, we're gonna rewrite this entire thing.
So it's like, do we want to do it now,
or are there other items more, you know,
with higher priority to tackle first
while we work on layers in the background in a sense i have a question i was reading the layers
paper and i could not uh quantify the let's say the the metrics improvement uh the did you guys have also this uh thought experiment how
faster would cardano go in terms of tip the you know the metric everybody's asking about tps
did you did you think about that or what's did you not look at that yes and it's it's also an
interesting thing that you should not look at Leos necessarily only in its best case scenario, right?
Because if you read between the lines, Leos under attack degrades into what we have today, right?
Into Praos, which means that the worst performance of Leos is kind of what we have today.
then the worst performance of layers is kind of what we have today.
And to me, that means, you know,
if you always only consider the worst case scenario,
well, layers is, you know, not better than what we have today
in terms of adversarial resistance.
Now, on the best days, right, if everything goes fine
and no one is attacking the chain, then that means you can possibly run
as fast as you could almost or as fast as your
network bandwidth uh and cpus allows which means that then we are actually constrained by the hardware
requirements we want to set on cardano and here in a sense the sky is the limit but we've always
been quite conservative with cardano saying you know we want a node to be runnable on a low-end hardware.
But I think Layers is going to open the door to, well, now that we have Layers,
that means if you have a 32 core CPU with an immense amount of computing resources,
you're going to get much, much faster transactions.
So everyone's going to race to, you know, increasing their hardware potentially potentially and that means we might lose some decentralizations because of that
since we're gonna remove people from being able to participate to the
consensus because the hardware becomes too expensive so it's kind of a weird
balance and if we stick with the hardware requirements we have today yeah
that means you go around like no you know, 1000 TPS relatively easily.
And we can go beyond, but that means, you know, increasing the hardware and increasing the
network bandwidth and possibly reducing decentralization because of that.
Yeah, I think in general, Ethereum has a concept called PBS that has some conceptual overlap
concept called PBS that has some conceptual overlap with Leos. Obviously they're fairly
different, but conceptually there's some overlap. And so I feel like the concept of Leos is kind
of an idea whose time has come and different blockchains are kind of looking at these kinds
of concepts as a way to improve their chains. So I think maybe we can agree on AASN.
This is probably something we'll have to do in the future.
The question of how much do we want to do it now,
given that there's a lot of prioritization work we're doing
with lower hanging fruit.
But I think generally speaking, we want to get this done anyways.
And it is a roadmap that will take a while to build.
It is a non-trivial change.
So I think it's better to work on it now in the background
as other efforts go on.
So it's A. Are we all happy with A?
Yeah, A or B eventually.
I mean, if we have too many items in A,
that's the first one I would demo it to B.
OK. OK.
Fair transaction processing.
Yeah, this depends on Leos mostly.
So this is, can you elaborate on it, Seba?
What is fair transaction processing?
Yeah, so basically the core thing is that blockchains have limited bandwidth.
You can't have infinite number of transactions. And there's some use cases that
depend on being able to have fast transaction processing for the use case to work.
So for example, imagine you have a lending protocol, you've loaned your token to somebody,
as long as the price is not below the same price, like you don't get liquidated, this kind of thing.
You might need to add more collateral to your position to avoid getting liquidated.
But if the network's under congestion, it might take you a few hours
to go through. Obviously, it shouldn't take a few hours, but theoretically, the worst conditions could
take a while.
And what's made it even worse is that oftentimes the kind of situation where transaction processing
takes a while is also the cases where the prices move the most.
So for these specific things,
people would be like, hey,
I need my transaction to go through right now.
I would lose a lot of money if it does not go through.
There's also other things like layer twos
that might say like, hey,
I want my transaction to go through faster
because my transactions not represent one user,
it represents an aggregate history of multiple hundreds
or thousands of users doing different actions.
So the way blockchain has tackled this historically is with the fee market, which is the more
you pay, the sooner your transaction gets included to the blockchain.
There's of course some concern of the impacts of this kind of fee market, which is if the
chain gets really congested and the fees go up, it might price out
regular people that can't afford to spend hundreds of dollars on getting their transaction to go
through. So there's a lot of interest in trying to get a more fair system to process transactions
so that there's some way for these high, these like latency sensitive use
cases to go through, but without pricing out the average person. So there's some ideas around tiered
fees for this. There's some ideas around layout and how to architect layout around the idea of
and how to architect Leos around the idea of para transaction processing.
I believe Leos gives us the smoothest way to integrate this because of the Leos architecture,
where Leos, if you don't know, already kind of splits up the network into different buckets
operated by usually different pools. And you can submit the different buckets if you want your transaction to be picked up faster.
And so Leo kind of gives us a nicer way to get this kind of fair transaction processing,
but it's not wired conceptually.
um so hopefully i guess you get overview of the topic yeah um so matthias what what do you have
So hopefully that gives you a good overview of the topic.
any thoughts on this yeah i think this is kind of proposing a solution already to a question that is
um not um unanimous or output athletic that is quite quite polarizing as a question you know should we have
a few markets already this is kind of giving an answer to it saying no we should not because we
can have fair contact and processing instead as a way to you know share the bandwidth but i think
there is a a bigger question than that on top which is what about the fee market like what do we do in when we reach the chain capabilities and so I would see maybe more research from that
area no saying what are the possible options actually how you how can you
implement different fee markets if you have to or if you do you know don't if
you don't want to implement a fee market what are your options so that then we can
have a variety of solutions to pick from and decide which one we want to implement the free market, what are your options? So that then we can have a variety of solutions to pick from and decide which one we want to implement. Yeah, I agree with that. I feel
like conceptually we need this. It'll help a lot if we have a way to decide on this prioritization,
especially when it comes to the layer twos. But I don't think there's clarity on the best way to do it. I think most likely the way this will play out is people will do some core research work
on different ideas and propose some governance info actions and then the D-REP will vote
on different potential ideas.
And then based off these results, we would pick one to fund and implement um so i support this proposal in this kind of like
uh sense of not implementing it but rather doing a systemization of knowledge and trying to propose
the different options and then uh you know doing the governance proposals to get uh gear apps to
pick an approach and then then afterwards, you can actually
find the implementation.
Would you agree on a C tier, or you would put it higher?
C or D for me, yeah.
Yeah, C or D as well.
Then D, that's 2D.
Now we need to speed things up a bit if not
Seba goes to bed in the morning.
An interesting one, Minotaur.
Is it about implementing Minotaur?
This is foundational research.
Yeah, but the paper has been published on that already.
Yeah, and I think this is something...
So for people who don't know, Minotaur is about multi-consensus systems,
which is notably something that some partner chains are interested in.
As I say, imagine you want to build a partner chain that uses proof of work.
That's not really easily doable because your chain might get 51% attacked really easily
because proof of work blockchains are fairly vulnerable when they just get started. You want to leverage security from
Cardano. You want to have Proof of Work plus inherit security from Cardano instead of just
relying on Cardano specifically. Obviously, Midnight is one of those chains that's interested in Minotaur. There might be others that come up.
I think it is kind of an interesting problem.
I'm not sure how much Cardano needs to be the one
putting out the money for this.
Although it does enable new cases on Cardano,
I think historically, if you look at layer 2 on ethereum most people are okay with just saying
oh I don't want to introduce my own resources and consensus I want to just fully leverage
ethereum's consensus um so if a lot of projects are okay with that do we really want to invest
the massive amount of time from the cardinal budget into enabling this
um so i think in my opinion here yeah i think it's probably the like but it's already a research a sole research problem in the sense that we've published a paper on that that explains you know
how it should work so now the next step is to implement it and i would love to see an
implementation of that really uh but it won't happen on Cardano that's necessarily going to be on a
layer two or a sidechain or a partner chain whatever you want to call it. So should that be
super high on our priority list? Probably not but is this an interesting thing to showcase most likely yes also because as a concept we can then reuse for
multiple layer twos so yeah so we agree on a low impact dt or not recommended
I wouldn't go as as low
well you can say and we do an average.
I mean, it's an interesting item.
But as Sebastien said, I don't think this is, like,
pertaining to Cardano, so to speak.
Right?
It's about other...
Yeah, but this is the Cardano budget, right?
I think we can have also protein folding is a very good research topic, but we... Yeah, but this is the Cardano budget, right? I think we can have also protein folding
is a very good research topic,
but we would...
Yeah, exactly.
I would say off-topic then.
From a purely Cardano perspective,
it's completely off-topic.
Yeah, let's agree.
It's an interesting one.
Shall we say not recommended,
very cool, but maybe not Cardano,
or we can leave it in the question mark tier if uh if we don't
wanna okay can we have it here like if there is any money left i mean that's low low impact let's
put low impact per sec yeah yeah still but what do you say is that you fine with d or f yeah i think
i'm fine with d. OK. All right.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view.
Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Proof of view. Because I don't know a single project that's actually building with this at the moment.
That's by the fact the research paper came out a few years ago, and it depends on Mentor,
which is not in production yet. So it could be revisited in a future budget next year.
I think putting the budget for this year is maybe overly optimistic.
I like it. We are coming with a good balance distribution.
Congestion control. Yeah, I think this is really related to the fair transaction processing. So maybe just
bundled together. Yeah. Although I would say it's slightly more interesting.
You know, I mean, it's like we've always been using transaction fees,
and you often hear about, like, blockchain that are like,
hey, we are a fee-less blockchain.
And then, you know, when you start digging a bit,
but how do you ensure that, you know, your system doesn't get spammed?
Usually, there is no solutions behind.
Or at least I haven't seen any system that is fee-less,
and that can also guarantee no security and and and operational
operationality of the system so that is an interesting research area but definitely not
a top priority so c or d to me maybe more c can you leave with c sebaba? SEBASTIAN BASTIANI- Yeah, I agree.
It's a bit more general than pure transaction processing.
There's other ways to tackle the problems, so I agree.
SEBASTIAN BASTIANI- Yeah, they could be merging one and be kind of C tier.
Yeah, I agree with you.
Tokenomics design is very vague.
It's probably, again, we could bucket it with the congestion control, and it's a bit more
of the tokenomics.
I mean, there's a lot of discussion
around tokenomic design related to what should the parameters
be for stake pools, how much should stake pools earn,
all these kinds of things.
I think it's a debate that's been going on for years
with no clear consensus on its specific path.
And I think it's focusing on trying to split up the pie we already have
as opposed to growing the pie,
which I think is just not the right thing to think about.
What difference do you make with the the next the
next item actually the reward sharing and transaction fees i think they're pretty related
i think a lot of people i mean the token design is not just this because it also involves i think
like the how much of the treasury tax be these other kinds of things how should the how should the inflation be set so i think it's a
bit more general but i do think like um yeah they're very very closely related because about
the the parameters the protocol parameters cf did some research about a zero and k i do see some
value in it but i don't it's not for sure it's not the top priority, right?
Yeah, but I think like...
High actually, because I mean, the rewards are getting worse and worse every year, right?
Every four years or so, we get less rewards.
And we are not seeing the uptick in transaction fees at the moment that will counterbalance that,
which means that effectively, you know, the chain is less and less attractive for people. And that means it's becoming a pressing
problem, actually, to find better incentives and better ways of sharing rewards. So arguably,
that's quite high on the list. Yeah, I think I agree in a sense, like what it says, I think I agree in a sense like what it says. I think we should be focusing on trying to increase the pie.
That comes in concepts like these Babel fees
and concepts like Leos or Paris or Mithril,
the AdMor features the Cardano's stake pools.
It comes in the partner chains that might, you know,
give extra rewards to the stake pool.
There's a lot of different budget items that are meant to bring in new revenue to Cardano,
new services that Cardano as a blockchain can offer. And I want to focus on building those
out and making them do well as opposed to trying to do any kind of rethinking of how we split up the current pie.
Maybe to put it in a different way, if you look at some of the blockchains out there that have become profitable,
Bitcoin became profitable through NFTs, Ethereum became profitable for DeFi, and then later on NFTs,
and then later on through Layer 2s, and Solana at some point was profitable through meme coin.
All that to say is that for these existing blockchains,
oftentimes they reach profitability through just one thing that really pops off.
And that ends up bringing a lot more revenue than trying to think about optimizing the revenue they already get.
So if the tokenomic design item is about
how can we best architect Babelfeast, for example,
to bring in more use cases, like, you know, one thing for Babelfeast,
like, can we enable payment of transaction fees in Bitcoin
to onboard the Bitcoin users onto Cardano?
You know, these kinds of things. And then if the tokenomics design is like, how can we make sure
these use cases succeed and bring the most value to the Cardano blockchain, then I definitely agree.
If the tokenomics design is going to be like, well, based off my reports, the treasury fee should be
19% instead of 20% or something like that, then I think it's just not worth the time.
19% instead of 20% or something like that, then I think it's just not worth the time.
Yeah. I mean, without adoption, you can have the best tokenomics design. It's not going to work,
right? We need adoption is king and then... Yeah, but given also the circumstances,
right? We're governance, we're entering this era where we want to spend money, that is,
in the treasury, which means that all these topics becomes more and more relevant. So yeah, for me, that's at least a B tier, but also with a disclaimer that
Seba just said, right? If it's actually about thinking of how do we make this, you know,
increase the pie and not just rethinking what are the parameters we currently have.
I mean, ever since we created the CIPs, right,
every now and then there is a CIP
about changing completely the reward scheme of Cardano.
Like every six months there is a new CIP about that.
So there is a need and a desire in the ecosystem, I think,
to review a bit some of the incentives
we've originally designed for Cardano.
And so that makes it an important item.
Are you fine, Seba, with B?
I think we... Yeah, just with that caveat, then yes, I'm okay with that.
Decentralized identity and reputation management.
Wow, this is a long description.
Yeah, I think this is the kind of thing
that people have spent a lot of money on. So for example,
IOG has spent a lot of multiple years of effort trying to do decentralized identity.
I think it is something that a lot of projects are super interested in for a variety of reasons.
It's a bit hard to do without ZK. And so I think at the end of the day, a lot of the identity solutions are nowadays revolving around ZK identity, ZK passport, these kinds of things.
I would not say it's all just on ZK's side, but I think it's like a lot of the DID stuff is around that.
But I think as I mentioned previously in this video, there's a lot of interest in real world assets in general.
So I would conceptually put it A or potentially higher.
The only caveat is I think a lot of things we would need to get these decentralized entity stuff working properly requires the ZK tech StarStream to be built beforehand.
Because if you want to do, for example,
like, OK, I can prove that I am in the EU
without proving which country I'm in, these kinds of things.
A lot of these require...
I mean, I don't disagree with you.
I agree.
But I think we get into an application layer
that is a bit different from every other item.
For instance, I would argue that DeFi is very important, right? But it's absent from the
roadmap because it's a more of a application layer type of item, right? And I think for
decentralized identity and reputation management, I see this item as very important. However, it does not fall into the layer one Cardano
roadmap necessarily.
That's kind of the problem to me.
It should, I think.
It should.
You think it should?
Yeah.
So I would put it in S, actually.
So for two reasons, mainly.
It's a use case enabler, right?
So it gets A tier at minimum just for that.
And in terms of building products with that,
I don't think we need to invest that much effort into research there,
because there has already been tons of research on these topics.
So it's about time we kind of start shipping solutions
on the decentralized identity layer.
And the second is what you just said, right?
It looks like it's something which just live at the applic identity layer. And the second is what you just said, right? It looks like it's
something which just live at the applicative layer, but actually we feel we need it at the
layer one as well as part of the governance, for example. If we want to implement effective stuff
like quadratic voting, we're going to need some kind of identity layer. For many layer two
application, it's also useful to have an identity layer. And I think there is a lot we can do without ZK as well.
Like ZK is definitely an area where this could help.
But if you just consider what also exists out of ZK,
I think there is a lot we can already deliver,
and a lot of groundwork that can be done.
And that could enable some use cases.
So I would say S2.
Yeah, I agree.
I think it might say it's at least A.
I think the stuff that would make it S
is stuff that's being built in parallel.
But I think we can put at least A in a B open to S as well.
All right.
So guys, I think we need to speed up.
I get some angry messages from people to speed up.
So I don't want to do a part two.
Let's do a part two about another topic.
Were we supposed to complete that in an hour?
80 minutes. We have 80 minutes. I think, I mean, I have time. So but let's...
Yeah, I think we have 25 minutes left. So I think we should be good.
Yeah, let's speed things up. I would suggest let's go call the turkey like we we we say what tier
it is and then we we we fight it over and then if we have consensus we can
um next level governance protocol now we can discuss one hour about this
uh research well it is important. What does that even mean?
Yeah, I feel like this is a bit vague.
You'll have to go through DREP voting to see if people are interested in these ideas first.
I mean, can we sort V1 governance first already?
Because I'm not sure we have completely sorted governance
yet shall we agree on a on a tepid c tier for this one um i mean depends really what it includes
because the title is a bit uh click baiting yeah that's true
low impact is not a high priority seba what do you think can we live with b or c yeah i put d i think there's a lot of people worked in place before going so we put governance incentive together. Do we agree?
I think this is paint DREP, in which case I would put F.
Yeah, I would also put F on that, mainly because that's an...
I don't think it's an answered question yet.
I mean, there are still people disagreeing that this should even be the case, that we do it.
And it's something we can fully do at the new applicative layer.
So I don't see why we should work on having first class
support in the protocol for that yet.
If you want it, do it with smart contracts.
We have very capable smart contract.
They can just, they can do that.
Yeah, if it is, move on.
Nice.
If you feel we need to discuss things let's do it right it's i i have time until yeah light client infrastructure oh that's that's a good one foundational research
i could be convinced of either s or f on this uh The reason why is because when people refer
to like client infrastructure,
there's usually two different things they're thinking of.
One is how can we connect your blockchain to another?
So for example, how can we have the Cardano like client
implemented in a Ethereum smart contract
or in a midnight smart contract or substrate like Inc contract,
which is like really useful for these kinds of bridging
solutions and bringing more users into Cardano, which I think is really important. But there's
another case of like light client infrastructure, which is how do we make light wallets more secure?
So as far as like when it comes to connecting Cardano to other blockchains, I think that's super important.
And having a really good secure solution for this.
So I'll probably put that into S tier.
Especially if we want to do this Bitcoin DeFi, we basically need this.
When it comes to helping make like clients more secure, I think it's F.
I think everybody's already okay with the security.
Nobody's talking about it. None of the users really care.
So that's kind of the caveat.
Matthias?
I would label it as duplicate in a sense
because there is another item
about having mithril improvements and mithril enhancements.
And I think if we have better Mithril supports
and we get like-lient infrastructure for free, in a sense.
So I would rather invest time and effort in Mithril
because it's also something we already have that's there.
It's just demands to be used.
So it just needs a bit more love.
So, yeah.
Shall we do...
Okay, so I say Mithril S, like client infrastructure.
Yeah, I would be okay with that.
Yeah, it looks good. I'm convinced. Consensus innovation, what the hell is this?
You mean beyond videos? Is it Peres?
Yeah, reading a lot of this, I think it's probably, again,
duplicative.
It talks about some BFT stuff, which
is a bit what Peres is trying to bring.
But I think basically
this item
is meant to kind of cover
a bit of the Paris work,
a bit of the Minotaur
work, a bit of other work.
So there's some roadmap
items that are meant to be these
more general
directional things.
It sounds to me like new research, kind of like more general directional thing, which I'm not.
It sounds to me like about new research,
like finding new consensus protocols and new algorithms.
So like it's really pure research in the consensus space.
And as much as I find that, you know, interesting,
I'm also like same as for the, you know, what we said before,
like proof of useful work.
Should Cardano be funding this kind of thing directly?
Not sure.
If we're committed to layers already as our new next upgrade,
there will be no time to implement another consensus
protocol anyway, unless we find something which
is even better than layers on every metrics.
But good luck proving that.
Should we do low impact or D or F?
I would put F.
Matthias, you're the tiebreaker.
Yeah, the related one is FastBFT, which
is related to consensus innovation, which is basically
if you build a partner chain or layer 2, you might want to have...
Yeah, I mean, mostly partner chain, you might want to have some BFT consensus on it
for it to be faster.
Notably, Midnight and Quantum Husky are, I think, looking into these kinds of fast BFT
research items, and there's some research cooperation
with some other entities on this.
Although I think it's really important,
I don't think this is as much of a Cardano item.
It's more of a specific partnership.
Like, you just pick Mystic City, right?
It's like a consensus from SUI.
And you have FASB-FTEft it's like there is no i mean
yes there is always research that can be done on this areas but it's really not high on the
priority list to me f agreed yep i i like that the community tier list there were only a's and
now we have like the majority of the things in there. Tonight, don't go out.
I mean, I think we're also much more pragmatic in the sense that we'll have to build some of the stuff.
So I'm like, I'm not going to build things
that I don't believe in, you know.
Anti-grinding.
That's a cool one, actually.
Yeah, conceptually, so basically trying to make the network a bit more secure
by avoiding potential attack.
I understand that there's some theoretical stuff
that people have talked about in the past.
I don't think they're super likely or top priority,
especially if you think about the work we have to do for
Paris and Leos. I would prefer not to spend time on something that I feel is not
practically something that's really an issue. Yeah, so I mean if we have Paris, in a sense,
the grinding is already diminished. Like what you can do by grinding, right?
So the impact of those attacks is highly diminished.
And definitely, I would put more effort into PERAS than into that.
But I would still kind of like to see a paper maybe explaining, you know,
what changes you would have to do to the existing protocol to make it more grinding secure.
And, you know, lower than also the settlement in that sense because that might be actually way easier than implementing the full Paras. So if that is a close reach, low hanging fruit, I would definitely put
some effort into that. If you tell me that's going to be a five or ten years research report, no.
Yeah, and I think we kind of skipped talking about Paris too much because it was kind of bucketed into our discussion about Leos.
I think Paris is a really good idea.
It basically makes the finality for Karam much faster.
I think the current target finality mentioned in a lot of the docs for Paris
for Paris is still too slow. I think we should aim for at most finality in a few blocks,
is still too slow.
if not one or two blocks. I think we can get there. It's just that the current research work
takes one approach to get us to a certain point, and then we can bootstrap some other protocols on top of it to get us in faster.
And I think, like Matias said,
if we solve those problems in Paris
and make Paris even better,
it gives us a lot of this anti-grinding for free.
Because one of the reasons Paris is not as fast as it could be
is precisely because of some potential grinding attacks against it.
Maybe not grinding attacks, but things related to grinding attack.
So I think a lot of this is actually should be bundled under pairs as opposed to a separate
roadmap item.
Yeah.
So what do we do with it? We put secondary consideration C
or we put it in not recommended
because it's under PERAS?
I think C is good,
but I would still put a disclaimer like,
you know, provided that this is not already tackled
as part of PERAS.
Or maybe you can do both in parallel,
but like anti-grinding by itself is interesting,
but it's kind of, to me, I just see
is it a subset of Paras.
It's a way to subdivise the work on Paras.
I see we have a duplicate.
Error Snarks.
Oh, recursive snarks.
Yeah, so recursive snarks are a technique used by Midnight.
Basically, what it allows you to do
is combine proofs together.
So if you have a proof from A to B and a proof from B to C, you can combine them together to a single proof from A to C. Conceptually, it's really interesting technology. There's other blockchains
that have this implemented in production, like Mina. The problem is that conceptually, this is not the state of the art, so to speak.
There's some other ideas around bullying schemes that tend to give you some better performance
that inherits some ideas from recursive SNARKs.
And the recursive SNARK productization already exists under Midnight.
So Midnight is already doing recursive SNRX.
So I feel like this is conceptually something
that we should spend time on.
I think the name is maybe not the right one.
That's to say, I think we should be able to get ZK directly
on the cardinal layer one.
I think the way to get there while maintaining
the low node requirements we want is probably folding schemes
as opposed to recursive SNARKs.
And that's kind of what we're doing for StarStream or ZKBM
that we're working on.
And so I would leave the recursive SNARK stuff
to midnight, which is already pretty far
in the productization of this technology.
And my understanding is meant to ship later this year.
So as opposed to recursive snark specifically, more generally the idea of allowing DK Proust
to settle to Cardano in a way that is efficient.
I would put it at A, but it depends what they plan to spend the money on.
I think this could easily end up being spent on the wrong thing.
Yeah, I mean, I wouldn't say it's a top priority. I would possibly just put it under B,
it's a top priority. I would possibly just put it under B, you know, for the reasons you just
mentioned, right? It's an important thing. It's an interesting research area. And I think Midnight
also is the only one researching this kind of thing. Pretty much every single ZK platform today
is interested in solving that problem. So I'm surprised even that there isn't some kind of
consortium about, you know, finding, you know, solving the recursive snark problem and having multiple actors being part of that.
If, you know, there is such a thing, we should be part of it as Cardano.
I mean, in the sense that we should have people and industries working towards that so that we are not just left behind as an ecosystem.
So it's definitely important yeah
and it's gonna be on the use there but yeah yeah there's like some of that so like the
recursive snacks for midnight is not entirely from scratch rather it's part of the halo 2 family of
etc protocol along with a few other blockchain uh the stuff we're building for star stream is part of the nova family uh which is some work done by some other companies like aztec and microsoft and a few other
and he's out there so for all the zk stuff i think usually people don't usually go at it alone and
rather a part of these like families they're not uh foundations or like associations per se but like
groups of many different blockchains
banding resources together to work on these so we what i would put in in s is something we don't have actually on the road map here which is just snarks you know having more support for snarks in
cardano and recursive snarks becomes an important initiatives but not a top priority or an immediate
imperative to me.
Yeah, I wanted to discuss five minutes at the end, what's missing.
So that's a good point.
So we have as narcs, I put it in B,
so because I agree with...
So technically we have some of the building blocks
to do that, but the fact is that we've got them
for almost a year now,
and there is still no actual solution that has emerged
that is usable today on Cardano with that,
which kind of, you know, indicates that either
they are missing better support, or there is just,
you know, not enough money to fuel all the efforts there.
Yeah.
Proof of restake.
I think this goes in the direction of Eigenlayer.
Yeah, so it's basically,
I see this as kind of an extension of Mithril.
So Mithril gives you a way to build overlay networks on Cardano.
Restaking is a similar kind of overlay network,
except instead your funds are usually at risk
if you do some behavior incorrectly.
So it's like, consensually what event load gives you
plus some extra conditions.
I think if you like an eigenlayer,
which is a network that does this,
it is at a market cap of a few billion, if I recall correctly.
So it's something I think a lot of people have a lot of interest in. I would say there's no big
use case on Eigenlayer that's production-ready today, but there's quite a few companies
building on top of it. So I think it makes sense as a way to extend Cardano to allow more different kinds of use
case to be built on it.
So I'll put it at least A. I think,
although there is work we can do with just Mithril
as it is to enable some really cool stuff,
I think this concept of restaking actively
validated services could enable a lot more.
Yeah, I agree.
I would put it at least in A.
Matthias?
I would put it after Mithril
announcements, for sure.
Because I think
we can do a lot
with what we have today on Mithril,
and I would rather develop Mithril than
thinking about the potential
use cases.
But, again, that's also a use case enabler,
so it get at least A for me.
And yeah, I mean, I'm fine with A.
Midgard, optimistic rollups.
Yeah, so a lot of, I think everyone knows also about Myrdgaard now in the ecosystem,
it's made quite a lot of noise. It's a very promising one. I'm not sure if they have released
the paper or not yet. I mean, I've seen some draft of it. I think it was at some point
released publicly, right?
Yes, yes, it is on our GitHub. So, OK.
There is a lot of good ideas in that.
From what I've been also hearing from the Anastasia lab team
is they're building that in a way that makes it possible
for people to kind of contribute and be part of the development.
So I'm really eager to see that being open source.
I think it is also a very good use-kate enabler.
So it goes next to Hydra in that sense.
I would put an S on A on that.
I really want to see Midgard out.
And I don't want to have another L2 project that just fans out
and disappear from cardano yeah i think from my side um i think
this optimistic roll-up stuff will definitely have a faster performance compared to like the
recursive snark work uh for at least the next like two years and so i would say it depends how fast
they can they think they can get Mayguard released.
The reason I say this is because you think about it, for example, Optimism,
which is an optimistic world for Ethereum, came out, I think, like 2019, 2020,
is like when they released their testnet.
And to this day, they still don't have the full fraud proofs enabled,
if I remember correctly.
So it turns out it's a lot harder
to build than they thought. And BigGuard is also a bit tricky because they need to generate fraud
proofs of the ledger rules, which I think is a bit hard to get right and will require a lot of
domain experts to look into it. And so I think the biggest question is how fast do they think they'll be able to get it to market?
So for me, it's between an A and a B, depending on speed to market.
So we have consensus on A.
It's also interesting to see which layer 2 people are going to pick for the different use cases.
Like they're going to do a partner chain,
Midgard, they're gonna do Hydra.
It's, yeah.
So are we good with A or,
Matthias you wanna fight?
No, I'm not for S, although it could be.
We cannot have too many S's, right?
Yeah, exactly.
If there was maybe a more precise item of like,
you know, a subset of Midgard that is maybe in restricting
some of the transactions to make sure that, you know,
the fraud book is doable and so on, like, okay, S.
And I'm fine with an A otherwise.
I would just like that to see Midgard live
as soon as possible.
For the revised stake pool incentives,
I think we can bunch it together here, right?
Yeah, that's the doing with the reward sharing
and transaction fees.
Yeah.
Nested transactions.
Yeah, this is the one that I'm not sure of.
So basically, if you're not familiar with this,
so basically, one of the issues that's a bit hard to tackle
in Cardano is transaction chaining.
When you have a few different actions you want to chain together,
it can be a bit tricky.
It requires you to make multiple separate transactions.
And then these are hard for explorers to deal with,
a bit tricky for wallets to deal with, a bit tricky for wallets to deal
with, a bit tricky for dApps to deal with. And so one of the solutions that has come up a few times
is, well, what if we allow transactions of transactions? So transaction inside
contains both other transactions and says, oh, please run all these transactions atomically.
It does solve the issue. Other people have tried this.
For example, there's another UTXO-based blockchain called Fuel that has this functionality.
It just does not feel like...
It feels a bit hacky.
It's like, oh, we'll just have transactions of transactions, and then it's something. But I feel like we should probably give more thought
about why are we trying to nest the transactions?
Is there a better way to solve this?
I mean, in StarStream, which is the ZKVM,
we try to tackle this instead by allowing you to iterate
UTXOS multiple times with the same transaction. Instead of duplicating the entire transaction content, you're just allowed to
chain UTXOS multiple times, which gives you the same equivalent functionality. It's all this way,
but I think that would be much harder to implement in Plutus, which obviously is what a lot of the existing infrastructure is built to deal with.
So although it is a bit hacky, I think it is the easiest way to enable this
in the protocol as is, and would make implementing some dApps and simplify,
like, make some of these dApps a bit easier and simplify
some of the behavior of some of these
wallets and explorers so i could be convinced either way on this issue
matthias what's your take on it i'm not fully convinced because i think that's a problem we
can already solve at the smartphone hack level not necessarily in an optimal fashion but if you look at solutions like bullet
you know you can have intent based contract that will give you some of the same capabilities so
therefore this is not an immediate problem we have to solve at the layer one level and I would be much
more seduced by solutions like you know start stream
that Sebastian is describing where we know the limited continuations and and possibly just
rethinking the way we execute smart contract entirely rather than complexifying the transaction
execution as a whole right so it's like hey you want this particular kind of thing that you know
the necessary transaction give you like you want want this intent-based divisions of your smart contracts,
well, use this type of script and this type of VM.
And we have a ledger already that supports multiple languages,
to support multiple VMs.
People don't realize that, but technically what we have in Cardano today,
we've produced V1, V2, and V3 are three distinct VMs.
So adding a fourth VM that would have a different semantic
would not be that much more complicated.
And so I would rather go on that path
than what's being proposed currently
with nested transaction.
So maybe C or D for me?
SEBA, C or D, what do you think? I would default to D.
I could be convinced of C if somebody made
really passionate arguments, but my default intuition is D.
LSM, so I think this just makes no useless memory, right?
Yeah, that's one of the things that I could be convinced also, I guess, for C,
sorry, for S or F equally.
I would argue for S in the sense that this is work that's been in the making
for the past three or four years already.
It should, to me, it should already be implemented.
It should already be live.
It's also not solving a problem that we should have been solving.
I'm a bit biased here because obviously working on Amaru,
and we've opted for a drastically different approach
there, which is to pick up something from the industry that
already implement log-structure image trees.
There are plenty of databases that do just that.
So having to redesign an entire database in Haskell
to do that particular thing, I think, to me, was an overkill.
So it should be delivered.
And in that sense, it should be an immediate imperative now.
There is no way this item should be dragging again.
And at the same time, as I just said,
to me, it's also not recommended,
because there are already plenty of databases in the industry
to pick from that implement that solution just fine.
So but yeah.
There's too much effort on that to just drop it now.
Sorry.
Yeah, I agree that conceptually we need this.
If this is the right way to implement it,
I'm not convinced.
So maybe we can put it in the middle, C, which is like, we need this, so it's S, but also implementation-wise, who
knows, so F, so let's put it in the middle.
Yeah, hopefully people will look
at the context and the discussion, right,
and not just say, C tier.
It's a people will. That's the internet. People will just look at the results and the discussion, right? And not just say, I'll sit here. It's a... No. People will...
That's the internet. People will just look at the results and draw conclusions.
Governance improvements. I think also we can put it where... merge it with something else, right?
Yeah, that's the...
Yeah, I think this is more important than next level governance protocols,
like improving different governance. So I put it... Yeah, it's the... I think this is more important than next level governance protocols, like improving current governance.
So I put it...
Yeah, it's like...
Ah, okay.
We need that eventually, but it's also like,
let's get to what we have currently working first, maybe.
Timeless, timeliness market.
I'm not sure.
Is that related to transactions?
The proposed work would create a POC of a small change
to the Cardano nodes that would permit block producing node
to ensure, even under a trim Cardano loads,
the insertion of a transaction into the block
about to be produced.
Yeah, I feel like this is duplicate.
I mean, that is literally the liveness property
that every consensus protocol should have.
Yeah.
So the fact that on the roadmap
would indicate that our consensus is broken,
which I don't think it is.
Yeah. What is that? Question mark.
We leave it here then.
Partner chains.
Isn't it like a duplicate of another one?
Which one?
We've already discussed that, right?
The whole midnight partner chain minotaur
yeah so i assume this is more related to the specific partner train sdk
which is the substrate sdk that uh they are building for build easily launched their own
partner chains um to be honest i haven't looked into the specific part in SDK that much in detail.
I've only seen like presentations on it.
So I don't know the end results.
I think it's more general purpose than because here they say EVM based applications.
So I think the framework is more for a eigenlayer type of framework.
It goes in that direction. And I think this is the midnight first partner chain. And then
this partner chain is probably the connector to this kind of...
Yeah. But I think midnight is not using the partner chain SDK, because I think it predates it.
Yeah. I mean, there is a part of that thinks this is a use case enabler,
so it should go quite high on the list. It's about interoperability between chains.
But it also feels like this is not sort of protocol specific, so it has nothing to do on
a core roadmap. But yeah, I could agree with an A.
SEBA?
Yeah, I would maybe put it at B. I need to look more into specifically the partnership
SDK that they've been building and the progress on that and web blockers they've run into
to know if that specific implementation is worth pursuing or if we should rethink things.
I think conceptually, I agree it's a use case enabler that doesn't make sense.
When it comes to specific, this implementation is being worked on,
not sure. So I'd be okay with A or B.
You can go with B then, I think.
Yeah, I agree with B.
You've convinced me of B as well.
ZKFold Symbolic.
Oh, yeah.
That's the Haskell new language for creating smart contract
language that are like zero-knowledge capable that ZKFool has been working on.
I find it interesting that after everything that happens
around Q2CX, they still decided to make a Haskell SDK.
I thought we had kind of already a sense
that people don't want to write Haskell, generally speaking.
I mean, I love to, but I'm not a good sample
of the developer out there.
That's why we had Aiken and other stuff coming in.
So yeah, I have some reserves on that particular one, I think.
Yeah, I agree.
I think they have a lot of right ideas.
I just think the surface language they have for people to influence stuff,
you look at their docs, it's...
I feel like this is not super approachable to the average developer.
For the same reason, PlutusPx is not super approachable, so...
Yeah.
I have some trouble.
I remember discussing with ZK Folds, like, years ago, this particular thing, and my stance at the time has still not changed.
I think this would have been better introduced as an annotation system on existing languages to produce better UPLC that could then lead to zero-knowledge proofs, rather than a whole new language. So I think it's also not too late to pivot in that sense and you know
and then taken and Plutarch and other solutions to have annotations that would make the generation of
the proofs you know easier for them. But I really think that the layer at which this whole
stack operates right now is too high. It should rather target the uplc which is the common vocabulary for every smart
contract we have today yeah then in my opinion in my opinion there's kind of like three different
ways you can introduce dk to cardano one is that it's like a totally independent system that post
ek proves to cardano occasionally which is a you know similar to like the way a lot of our tools
work on ethereum it's the same way likenight will connect to Cardano. The second one is, okay, well, let's try and make ZKVM run directly on Cardano, and
that's what StarStream is building. And then there's kind of intermediates in between, which is, okay,
let's try and get a ZK execution of Plutus itself, which I think has a lot of different trade-offs.
Plutus itself.
Which I think has a lot of different trade-offs.
And I know this is something they've looked into.
And I think, as Matthias said, I think this would probably have been more clear of a win
or something worth spending time on as opposed to this like Haskell system they've built.
So should it be a secondary consideration or low impact or?
Yeah, I mean, it's been hard because, you know, obviously this is only by another company
who is a startup who could pivot based off feedback,
and they're not here in this call to talk about their project. So I'd probably leave it as a
question mark. I would probably go for low impact, but with a disclaimer again saying,
I don't think the ID itself is bad. I just think that the current interface to it,
which is a whole new language as a Haskell DSL
is not the right approach,
but it's also not too late to pivot to something
that could be more useful.
Yeah, agreed.
And if it was, you know, pivoted in that sense,
I would definitely rank it a lot higher
because that's a very good use case in April.
Yeah.
Ledger app rewrite.
I beg your pardon.
What is that about?
A new UI.
Oh, I think this is like natural hardware wallet.
Yeah, OK, the hardware wallet ledger app.
I see.
Well, I guess to include everything around governance, possibly,
as it's a bit lacking at the moment.
I mean, to me, this is very important.
However, then if we rank this high,
there's other items not in the roadmap
that are of a similar importance,
like Y-ledger and treasure.
I would put this in F, not because I think that's a similar importance, like why Ledger and not Treasure? Yeah, I feel like I would put this in F,
not because I think that's a bad idea,
but I feel like this is more of like a catalyst scope.
Yeah, I would agree. Project as opposed to a large roadmap item.
Yeah, yeah.
I would love to see something more generic,
like, you know, better hardware support,
but it's too specific in that sense here
to be on the core roadmap.
So, yeah. Alternative nodes. support but it's too specific in that sense here to be on the core roadmap so yeah alternative nodes
so there's an amaru item so so i'm slightly biased but i i go for s obviously but i can i can argue
i think it's it's actually you know building, in a sense, is what makes it possible to argue on such a roadmap, for example.
Having a single implementation means we have no points of comparisons, means there is no way we can even experiment with different solutions
to assess which one is the best.
And it's also by that means that we get to specify all the missing gaps
and identify the different problems
that the current implementation might have.
And even just makes it possible to implement completely new stuff
because the current implementation also
has to deal with all the legacy.
It has to go with the Byron era and all the four or five years
of development that's been into it, which
means you have way less freedom into exploring possibly,
you know, a completely new VM design,
where having alternative nodes means you can be a lot more agile on that.
And as soon as you've, you know, experimented enough with the design,
you can start thinking how you also integrate that
with your reference implementation, in a sense.
So that is definitely hype.
Yeah, I'd say from my side, it's probably also
S because although our company is not
contributing to a full node, we depend on this project
for some of the apps we develop at PyMA,
stuff like the chain abstraction framework we were building.
PyMA Engine uses these. StarStream stream the zkv i'm over developing also will depend on these for the initial launch
i would be surprised if other things like may guard end up launching with these initially
i think for a lot of the mithril stuff we talked about um would probably or like
proof of restate could probably end up launching
on these first as well.
It wouldn't surprise me if even Leos was implemented
on these alternative nodes sooner than the Haskell node.
So I think in general, it ends up being a pretty large force multiplier
in the ecosystem by allowing people to prototype stuff
and get stuff to market much
faster. Yeah. Yeah, I agree with you. I would put it in S tier. The criticism it could get is that
it slows things down if we need to implement everything twice, like consensus-wise. But I,
I mean, if that was the same team, right? Yeah, I, in fact, I mean, I put be true if that was the same team, right?
Yeah, in fact, I mean, I put it in S tier because I don't believe it's going to make things much slower
if things are done properly.
And the benefits we get out of it overweigh the slowness
or the coordination efforts needed.
Yeah, I think although there are cases
where it could make some stuff slower,
it's also forcing the Haskell
team to specify a lot of things. Like recently
they're trying to write specifications for a lot of
the ledger states and the networking stuff
that they haven't done until now because they
didn't really have a reason to do it. Now this alternative
node is forcing them to properly have specs for these parts
of Cardano, which is good in general.
It helps a force multiplier for a lot of them.
I mean, it's not something that falls entirely onto them, right?
Yeah. Being multiple implementations means that you can also start specifying a particular chunk
while the others are working on something else. And the collaboration and coordination that's needed,
it's not a bug, it's a feature here, here. We have more coordinations because that means we lead to higher quality designs and higher quality
specification from the get-go instead
of having to go into multiple runs of test nets
to realize that the design you've decided on was actually
flawed.
Yeah.
So I think there are some cases where maybe you'll
make the node improvements a bit slower.
But I think the impact, the force multiplier on building apps and use case to Cardano is worth
it because as was mentioned multiple times, so this call, like what we really care right
now is enabling new use cases and apps we've built.
And so if, you know, this alternative node allows us to do this much faster and better,
then it's worth it, even if it brings the productivity hit to the core node,
which also I'm not too convinced that would happen.
But I think it's definitely worth it.
And shout out to Dingo as well.
I see in the chat.
Indeed.
And all of them, literally.
Yeah, so there's Dolos, Amaru, TXPype,
and I think there's somebody else building stuff
in TypeScript as well.
In TypeScript and in Scala as well,
it's as started in C++ as well.
Daedalus Turbo is turning into a full C++ full node,
which I'm very happy to see.
So yeah, 2025, 2026 might be the year where we get not only one alternative node, but multiples.
Yeah, I mean, we see this in Ethereum. Like, Ethereum has multiple nodes.
A lot of them specify, like, being specific for different use cases. Like,
Hard Hat is very, very well optimized for local developer environments.
Boundary is really well optimized for local developer environments boundaries really
well optimized for launching uh layer twos there's another one is like ether except things like
really optimized for uh zk roll-ups um there's like a lot of these different nodes they're
optimized for different use cases um i think this has fairly strongly benefit their ecosystem
I think this has fairly strongly benefited their ecosystem.
I can't imagine doing anything like this just get.
Although get is really, really popular implementation,
and it works pretty well.
There's a lot of things where actually these other nodes
are more optimized for them.
And so that's why I can imagine the same thing happening
for Cardano.
I think it's been a net plus for them,
so it should be a net plus for us as well. Yeah. All right. Thank you, guys. I think we are done. I would suggest the following.
We could schedule a part two roadmap where we pick up the things that we did not discuss,
but should be maybe added and maybe a bit more look forward, like five, 10 years,
you know, quantum research and data availability.
We have account abstraction.
I would like to also to get a bit more info on the ZKVM
that you guys at DCSparts are working on.
So yeah, Ted, thank you so much.
I learned a lot and I hope this was helpful.
That was fun. Yeah, thank you guys very much.
I mean, for someone from a non-technical background,
I thought it was very interesting,
and I'm sure it was even more interesting
to those with the technical background.
Giorgio, could you go ahead and screenshot this
so we can save this?
Yeah, of course.
Yeah, of course.
Of course.
Of course.
Of course.
Of course.
You should not refresh the page.
You should just refresh the page.
We have the YouTube video for record, right?
Oh, yeah.
Good point.
Nice.
I have the screenshot.
I will tweet it.
Yeah, perfect.
Thank you, guys.
Say bye.
Have a good night.
And yeah, I also have a good night uh and uh yeah i i also have a good night everyone
bye thank you thank you thank you thank you bye thanks everyone
