Cartesi Lambada - a "worse is better" initiative

Technical Vision Forum Technical Evolution Plan
21

I would like to start off by saying that this conversation is refreshing and showcases a huge success of the Vision Forum already. It’s nice to have this discussion in public, in a long-lasting form where everyone can access, comment, and learn.

Now, getting back into the debate:
I’m confused for a very specific reason: I agree with most of what @carsten.munk is saying. I agree that we should support multiple data sources and different sequencers. I agree that a good percentage of apps won’t need the full security, censorship resistance, or decentralization of Ethereum, and many likely won’t even want a fraud-proof system that is super complex. They will be fine with a quorum of trusted entities, even a single authority or some kind of financial agreement. I also agree that some appchains will be okay with their nodes running only on super expensive computers, and that some appchains will prefer small epoch sizes so that their side-effects can be acted upon faster.
And I believe most of our technical contributors agree with this too, at least those who are thinking about the future of rollups and the implications of what we’re building.

What I don’t understand is why this is being framed as being incompatible with Cartesi Rollups. That’s probably why @tuler mentioned in his comment that he was afraid of Lambada “ending up having to solve the same problems rollups had to solve.”

I think there are a lot of cool ideas in what you’re suggesting, including some innovative concepts that I still need to fully grasp. However, my current understanding is that the suggestion essentially boils down to accelerating the focus on stack flexibility (ability to switch Data Availability layers, use different sequencers) rather than disregarding the Cartesi Rollups codebase and focusing on a completely new codebase.

The complexity of the rollups codebase, which is constantly being simplified (on-chain architecture, new node, output unification), mainly arises from the focus on side-effects and settlement - which is crucial for managing assets and TVL. Bridging is the most challenging part of a rollups stack, both conceptually and in terms of coding. I think once you add this capability to Lambada, its codebase will become much more complex and similar to the rollups one.

However, It feels to me that focusing on the dehashing device is a great way to reconcile both visions!

Ending on a positive note:
“A nice ‘beta’ version of Lambada would be able to deploy thousands of appchains that leverage the Espresso mainnet, use ‘reverse gas’ (as mentioned in another governance forum post), and include an initial CTSI subsidy on deployment. It would also be able to read and communicate with Ethereum L1/L2.”

If you manage to do this, it will be an incredibly exciting platform for experimentation. And if you can do it in an agile way because you’re familiar with the entire codebase and it doesn’t include the complexities of bridging/settling, then by all means go for it (not that you need anyone’s permission).

1 Like
22

it will be an incredibly exciting platform for experimentation

I just want to highlight here that the main aim is not experimentation, it’s adoption and agility (experimentation ability comes with agility) . I don’t say anywhere in my posts that this is incompatible with the Rollups concept or that rollups wants to do. Rollups is probably just one mode that people can pick.

Let me frame it this way:

My opinion - we need a 90 degree turn - a radical turn in how we do things and how we approach adoption. There’s something wrong today it feels like to many. We want to do a lot of great things, fix our modularity, and have easy deployment … but when? What’s hindering us from doing this within weeks, or a month? I have my own strong opinions on this.

It’s time to take a look outside our ecosystem. Every single day the possibility increases that someone else does something incredibly worse than our solution, but that provides our value - that people love and adopt and are passionate about. It may happen a lot faster than even I think it’ll happen.

image

Lambada is an attempt to be ahead of that happening - by being such an internal project. There’s tradeoffs, there are implications. I sincerely hope that we succeed with our current culture, software architecture, approach, and offering. But it doesn’t hurt to try another, parallel way of doing things, just to be sure.

Who knows - we might be surprised what gets us adoption.

I’m here to dance and have people across web3 dancing with us under the big Cartesi beach umbrella.

1 Like
23

Nice proposal. I agree that being less opinionated on how to use Cartesi tech stack can be beneficial for adoption and ecosystem growth.

I do not fully agree though with your diagnostics that its a radical move from how we are developing today. Maybe its true in terms of message and how we present ourselves, but in terms of development tasks, since the launch of the Honeypot, most effort has been about solving technical debt, simplifying/decoupling the parts and improving interfaces.

Solving this technical debt, in my opinion, is what will allow us to go in the direction of Lambada and make the rollups a subset of possible applications.

2 Likes
24

Very nice proposal!

I do believe that there is a lot of space for experimentation with Cartesi tech and Lambada is doing exactly that, which is very welcome. Right now, it would be nice for the community to have a clearer understanding of what it is and the distinction between Lambada and Cartesi Rollups. Preferably using terms that are well established withing the web3 crowd.

Perhaps these specifics are not even clear to Carsten yet. And this is perfectly fine. If you never feel lost, you are not in truly new territory.

For example, Felipe mentions that Lambada fits the important niche of “sovereign” applications. This feels right, due to the lack of vouchers. And even though vouchers could be introduced to Lambada later, it would also kill some of its nice simplicity and make it less distinct from Cartesi Rollups.

The same can be said about other aspects of Lambada: IPFS deployment, reverse gas…

It would be amazing to have a sentence that immediately sends the reader into the design space of Lambada. Just like “Linux capable, Optimistic Rollups” did for Cartesi Rollups in the early days.

Finding such description is hard, frustrating and time consuming. But with enough discussion and experimentation, it emerges.

I’m very much looking forward to see what Lambada is going to shape up into. “Sovereign web3”?, “Decentralized Amazon Lambda”?

1 Like
25

A meta observation to start: this thread is, to me, a testament to the growing traction of the vision forum as a space for public deliberation and debate over technical features in the Cartesi ecosystem. Truly, an energizing sight to behold!

As for the substance, I am generally in favor of contributors in the ecosystem being empowered to explore novel ways to leverage Cartesi technology.

From a technical POV, I can’t lend much to the discourse. But as a high-level observation, it seems to me that:

(i) there are similarities and differences between Lambada and Rollups;
(ii) there are current limitations to what both solutions can achieve;
(iii) there is a vision for the future evolution of both solutions

I would be interested in seeing if, through further discussion here in the public forum, there is a path to achieving some level of deeper consensus on those three points.

It strikes me that an objective assessment and comparison of Lambada and Rollups in both their current and envisioned states would be highly beneficial to the discourse, and would enable the broader community of contributors (even the non-technical side!) to better understand the breadth and scope of the current proposal.

1 Like