Cartesi Lambada - a "worse is better" initiative

Technical Vision Forum Technical Evolution Plan
1

image
image1024×1024 99.4 KB

What is Cartesi Lambada?

Cartesi Lambada is a technological stack designed to provide an alternate means for people to adopt the Cartesi technology.

Additionally, in the Lambada initiative, we also promote an alternate culture of development than that currently exists in the ecosystem.

The main objective is to foster rapid adoption of Cartesi by developers - today; and foster wider comprehension of the Cartesi stack, facilitating its evolution, simpler deployment, and enhanced experimentation.

Lambada is the fun ‘working title’ of the project. Maybe cartesi.computer fits better? Suggestions welcome.

What makes Lambada different?

The main question posed by Lambada is: Does a world computer have to be so different than how modern cloud computing works today? Why does it need to feel so alien to developers?

tl;dr:

Build a container, wrap it in a chain description telling what sequencer to pick transactions from and what block height, and distribute the genesis state to IPFS and that’s your appchain.

Finance inclusion of your appchain transactions by customers in sequencer blocks & computation of your state, hiring service providers for your appchain, paid through “reverse gas” model, and a free tier model proposed.

Submit transactions through a sequencer network. We’re no longer tied to restrictions of the EVM as sufficient ZK-based off-chain computation technology exists today to bypass EVM restrictions.

For the rest, go read the WIP technical documentation: GitHub - zippiehq/cartesi-lambada :slightly_smiling_face:

Why does Lambada matter?

There is an emerging environment characterized by a modular choice becoming possible, combining existing blockchains like Ethereum, alt-VMs, high-capacity decentralized sequencers, atomic transaction inclusion, data availability layers, re-staking mechanisms like Eigenlayer, co-processors, and zero-knowledge proofs.

This environment will likely be fully in place by the end of Q1-start of Q2 2024 - and we think we will be ready to provide Cartesi’s core value in this environment. We already see the beginnings of this with the deployment of technologies like Celestia mainnet & RiscZero.

A core belief is that in a decentralized ecosystem, the more approaches that people can successfully adopt and use Cartesi technology through, the better.

The current offering of Cartesi Rollups to developers is more suited towards those who’d deploy on existing Ethereum L1 or L2’s, host their infrastructure, and who have a deeper technical understanding - and architecturally far away from that of the vision of millions of appchains envisioned with sequencers and data availability layers.

The Lambada stack is focused on enabling swift, iterative experimentation & deployment, and easier proof-of-concept development, aiming to efficiently deliver value to both end-users and developers in this dynamic and evolving technological landscape. In short: Lambada makes blockchain development fun again.

The stack is meant to be simple, easy to develop apps using, understandable, and possible to reason about by most participants in the ecosystem, to guide development, advocacy, and product direction.

Why?

Sometimes for a project, a “worse is better” approach is required to find PMF. Lambada tries to be such an initiative, aiming to be more adoptable by end users and developers - delivering value today, not tomorrow, or in 12 months - as a part of Cartesi, running in parallel, and pushing the Cartesi ecosystem forward together with it.

When will we have Lambada? Surely, first in 12 months and after several lengthy debates and hours upon hours of synchronous meetings?

Lambada has already been here since December 2023! Check out the work-in-progress code in these repositories:

GitHub - zippiehq/cartesi-lambada (main node code)

GitHub - zippiehq/cartesi-lambada-base-machine (Ubuntu 22.04 image)

GitHub - zippiehq/cartesi-lambada-guest-tools (based on machine-emulator-tools)

See the Real World Assets demo here, for something built with Lambada that’s deployed and works today:

Discord (Cartesi discord thread)

How do I participate?

Come contribute, lurk, test - complain over bugs, bad developer experiences, etc!

#cartesi-compute on Cartesi Discord is open and the GitHub issue trackers are as well.

Additionally, we encourage you all to join The Weekly Lambada Dance, every Friday, starting Friday 12th January at 09:00 BRT/12:00 UTC - it’ll be generally announced with a link to a Google Meet in #cartesi-compute on Discord along with an agenda. The call will be recorded and public.

The point of the call is to sync on Lambada matters, do short demos, and process improvements. The first call will include a code walk-through of Lambada and some guidelines on development culture.

We intend to generate technical vision forum posts and RFPs for CGP (larger tasks) and DevAd Seed grants (smaller tasks) as part of this initiative to attract fresh minds and new contributors to the Cartesi Stack.

Why on earth is the weekly meeting called “The Weekly Lambada Dance”?

View these two videos:

Are you saying we should drop everything we’re doing, get behind this initiative, and adopt this for our developer story?

Evaluate the output of the Lambada initiative on its own merits. If it brings genuine value to what you’re doing and/or want to do in the ecosystem, by all means, adopt it. Or join it. Or contribute. Or don’t. We hope you’ll like this - and our customers too.

What can Lambada do today?

The node code is 2000-3000 lines of Rust, so it’s pretty explainable (please join the first call for a walkthrough). We have the reproducible Ubuntu 22.04 with guest tools, too. We have the IPFS plugin.

The Compute primitive works - state CID + transaction input → new state and background snapshotting. It can do a webhook on compute finishing. IPFS access works. We have Eigenlayer-based software wrapping this compute primitive as well in progress.

Subscription to multiple appchains works for appchains using Espresso testnet (as it’s down currently, that’s our own deployment of it) and Celestia testnet - and you can query the latest state and block history of it. It can also submit transactions to an appchain just by knowing the genesis state CID.

We’ve deployed a test instance of Lambada and used it successfully with the RWA demo. You could probably deploy your own appchain in a few minutes, today, if you so wanted.

What are the skeletons in the closet?

Lambada isn’t perfect. But it gets the job done.

IPFS access is slower than it should be. We don’t have bridging yet in any form (but arbitration has been thought about). We aren’t backward compatible with Cartesi Rollups apps. We could handle failures (disk space, etc) better. Developer experience needs the last mile. Snapshotting is slow (sparse file generation, hashing). Governance of appchains needs to happen within the appchain and need good UX for this. Need more examples and better docs. Some better APIs around transaction inclusion.

We try to track them all at Issues ¡ zippiehq/cartesi-lambada ¡ GitHub

But what’s important: the main value is already delivered and demonstrated and we catch real issues found by end users/developers and we’re able to rapidly fix them.

What could it be doing by the end of Q1?

A nice “beta” of Lambada would be able to deploy 1000s of appchains that leverages Espresso mainnet, use ‘reverse gas’ (see other governance forum post) that has an initial CTSI subsidy on deployment and be able to read and communicate with Ethereum L1/L2.

Comments? Questions? Constructive criticism? Please ask in this thread or reach out :slightly_smiling_face:

5 Likes
2

Hey @carsten.munk the structure and explanation of Cartesi Lambada is great and really helps to understand the proposal in an unfiltered way. A few comments below:

  1. The new stack giving developers a new experimental ground which the advantages you mention is refreshing.

  2. Lambada providing a parallel route for adoption is noteworthy and can be super useful for the community. You could probably deploy your own appchain in a few minutes, today this provides a great entry point, and we would love to test this out at DevAd too.

  3. The work which has begun is refreshing to see, which forms a good base for this proposal.

  4. The proposal linking in with other initiatives in the ecosystem which can present multiple entry points for the community to get involved in is definitely a great way forward.

I like the name, it brings out the “fun” you mention to blockchain development.

4 Likes
3

First of all thanks an big kudos a lot for bringing this refreshing and new look on how cartesi VM can be deployed and used.

From the ecosystem point of view, I see a great adoption opportunity and exciting exploratory vibe while from Sunodo’s point of view, I see a brand new “delivery method” of Cartesi virtual machine which will eventually need more convenience and Sunodo should support as well.

Aside from that, I see this proposal with the following great points:

1 - Carsten´s proposal although gives a step back in some convenience already built for rollups, can give a fresh start for a bootstrap of an enthusiastic developer´s community, which can create the sensation that being part of cartesi moment is cool and using cartesi is cool. This is gold!

3 - From product market fit point of view, this new way of using Cartesi can open even further experimentation for PMF, which is also critical for tech adoption

3 - This new way of using Cartesi VM can attract other classes of protocols to collaborate and I see more collaborative than competitive with the existent rollups

4 - Convenience will adopt new forms and progressively deploy them. A technical challenge would be the diagnosis of what can be reused from the current convenience already created.

3 Likes
4

Very excited about the prospects of this proposal from the Ecosystem growth perspective!

Carsten and team have been crushing it over the last few months integrating with various projects (Espresso, Eigenlayer, RiscZero to name a few). Amazing efforts, and great to see these “modular” experiments converging into this larger vision!

Sometimes for a project, a worse is better approach is required to find PMF. Lambada tries to be such an initiative, aiming to be more adoptable by end users and developers - delivering value today, not tomorrow, or in 12 months

Its undeniable that the Cartesi Machine is uniquely positioned to be a ground for unique new innovations through rapid prototyping/experimentation (given its unique capacity to run existing software out of the box)

Nevertheless we seem to face some hurdles in reaching this “vibrant ecosystem” state that seems so close, full of unique experiments and projects.

A few key points I believe this proposal greatly tackles:

  • Making it easier to understand Cartesi: Currently the tech seems quite difficult to understand (black box), which makes it harder for people to adopt, trust and thus experiment/build on it (this is especially relevant for innovators/early adopters). A more understandable / digestible codebase would greatly help here, attracting more devs to this amazing piece of technology. It’ll greatly boost the ecosystem building efforts both from application builder and integration/code contribution side

  • Making developing on Cartesi even closer to a “cloud experience”: E.g. Deploying an application in a couple of minutes. This is something the project has been striving for from the start, and further leaning into this experience will only further improve the onboarding experience and allow for rapid experimentation/iteration

  • Cartesi needs to fully embrace its modular nature: Cartesi is a modular pioneer: laid the vision for app-specific rollups, a powerful alt-VM, before both were a thing to begin with). Modularity is where the Cartesi Machine can reach its full potential (think cone of innovation and beyond) and were Cartesi and applications builders, through experimentation, can truly seek and find PMF. Many verticals (e.g. Onchain gaming) heavily rely on custom stacks (alt-DA, low latency/shared sequencers etc). In order to be able to solve these customer needs, across various verticals with their different needs, a modular approach & custom stacks seem fundamental

3 Likes
5

@carsten.munk - thanks for sharing such a detailed and thoughtful proposal. The approach Lambada is taking, particularly in terms of simplifying deployment and experimentation, is quite impressive.

This is well aligned with our goals at CGP, especially in our efforts to onboard contributors and fund proof-of-concept experiments within the ecosystem.

I’m excited about Lambada’s plan to attract new contributors. RFPs are a critical part of CGP as well and I’m looking forward to aligning our efforts with Lambada to attract talented individuals and teams through grants.

3 Likes
6

I agree with the positive posts above!
I like alternatives.
I love simplicity even more.

An implementation with Ethereum as the “sequencer” and “DA” would help to compare this to rollups, and maybe show they are not too far apart.

The other side of the coin is adoption. It is hard, VERY hard to get adoption. It’s been hard with one option. Another option can give alternatives, but can also bring confusion and duplicate efforts. Is the idea to try to converge to a single architecture that would encompass modularity including what rollups already provides?

2 Likes
7

An implementation with Ethereum as the “sequencer” and “DA” would help to compare this to rollups, and maybe show they are not too far apart.

I would be happy to have a variant of subscriptions in Lambada (like Espresso, Celestia is now) that leverages listening to a particular event stream matching a particular VM id from a EVM-based sequencer contract on Ethereum - it should probably be rather simple to write. Filed an issue here:

The other side of the coin is adoption. It is hard, VERY hard to get adoption. It’s been hard with one option. Another option can give alternatives, but can also bring confusion and duplicate efforts. Is the idea to try to converge to a single architecture that would encompass modularity including what rollups already provides?

I think on 6-12 month scale the concepts blend so much into each other that it looks more like a single path. What I want to do isn’t “anti-” something. What I want to primarily do is give us the agility and shared ecosystem understanding to sail into this wild new sea.

Adoption is hard. But I think we also need to take a hard look outside the ‘office’ windows on how the world looks today and understanding how we best approach getting adoption.

Happy to discuss commonalities with Sunodo, as well, as I don’t think our ‘philosophies’ are that far apart.

2 Likes
8

What I want to primarily do is give us the agility

Understandable. Starting something fresh always gives you more agility, as you have complete control and understanding of the code.

But I’m afraid you will end up having to solve the same problems rollups had to solve.

I don’t know if the other posters here understand the assumption of this proposal that app chains are sovereign, and what they are losing with the lack of settlement, in terms of what applications can actually do.

1 Like
9

Very well written and impressive proposal. Huge kudos!

I’ll probably write many other comments on this thread, since there’s a lot to discuss, but I wanted to start with the complexity angle, hehe.

The Cartesi Rollup’s codebase and architectural design are notably complex, primarily due to the incorporation of side-effects and composability. Essentially, this complexity emerges from the system’s capacity to consensually finalize (the old meaning) states. In other words, it comes from its ability to settle state. The requirement for users to agree and act on the result of a computation means, for stateful applications, that offchain agents need to synchronize not only on the order of inputs but also on the frequency/clock of settling (avoiding constant settlements after each input is crucial).
The ability to settle also generates the need for a validator (authority, quorum, watch-tower, DAVE) and the ability of the Cartesi Machine to generate constant proofs of its state.

What I’m trying to say is the following: I think the simplicity implied by this proposal relies on the assumption that ‘Appchains are sovereign’. As soon as one wants to have side-effects, digital assets, and composability, all that complexity gets reintroduced, and this proposal becomes something very close to the current rollups architecture. Would you agree with this assessment?

I have many other concerns regarding IPFS, dependence on multiple protocols at the same time, governance/migration, composability/scalability, assets, and general complexity/usability… but maybe we should debate one topic at a time : )

P.S.1: I like the fun name better than cartesi.computer. Just have to check if the Lambda team won’t get mad because having Lambada and Lambda at the same time seems quite ambitious, haha.

P.S. 2: To those already being in favor or against this idea, I think you’re jumping the gun. Don’t take this as criticism, but this proposal has MANY implications and is definitely something that deserves to be discussed deeply before huge commitment from a significant number of grantees.

P.S 3: It’s important to clarify that my comments, criticisms, and questions are meant for the scenario where Lambada becomes the primary vision within our ecosystem. I wholeheartedly believe that as a platform for experimentation, Lambada is already a great success and promises and can become a fertile ground for cool developments. My current focus is to figure out whether I should advocate for Lambada as our main strategic direction and encourage our entire tech team to prioritize it. This requires a thorough understanding of its technical details. Please read my comment in a friendly tone :slight_smile:

4 Likes
10

Hello there!! All in for the fun :smiley:

@carsten.munk, simple question: in the current state and looking towards Q1/Q2, are we talking about sovereign rollups only? In that case, for now Lambada would not be supporting DApps that handle Ethereum-based assets, is that right?

Eager to see how easy we can create and deploy applications with this approach - will try it out ASAP!

1 Like
11

It is great to see all the work and passion behind this proposal.
I will need to understand the technicalities behind this project to come up with better questions.

For now, here are a few things I think we should be careful about:

  • Clarity is fundamental. An alternative approach to Cartesi Rollups should be developed and promoted on a completely distinct track. I believe you are on the same page when you consider a different name for this product. But that also means distinct websites, branding, and ecosystem/advocacy programs.
  • As a consequence of the previous observation, it’s essential that Marketing, DevAd, EcoGrowth, and CGP have a clear understanding of this distinction, the technical implications of Lambada vs. Rollups, the possible use cases, and target audiences. In other words, they need to be careful not to underestimate the complexity of working with an alternative product in an effective way.

All in all, I like and support different branches and initiatives with Cartesi’s tech. That is compatible with the spirit of decentralization and modularity.

4 Likes
12

I think there’s maybe a bit of term misalignment here :slight_smile:

Let me try to explain this a bit.

Appchains in Lambada are defined solely by their state - they’re ‘self-governing’. That is, they specify at any particular state height (starting with genesis block):

  • what’s the sequencer that we should fetch blocks & transactions from, in this current state
  • what’s the sequencer block height we started listening to that sequencer
  • what’s the base machine we should evaluate the incoming inputs with
  • what’s the application we want to put inside that base machine that should evaluate incoming inputs
  • (future: what host-guest semantics, etc.)

this specification is controlled by the application entirely and the parameters also decide what information makes it inside the application as metadata, beyond just inputs. The sequencer selection is modular as well, so there are multiple types and variants. There may be ‘finalized’ states vs ‘not finalized’ states in some sequencer technologies.

so, the answer to your question (which isn’t simple :joy: ) relies on “what are the parameters set in this specification”.

Assuming this scenario for a moment:

  • The appchain has picked Espresso Sequencer
  • Espresso Sequencer has made mainnet
  • In Espresso Sequencer, the sequencer nodes are restaking and is assumed to have very high economic security (some larger % to that of Ethereum mainnet)
  • Espresso Sequencer commits its DA to Ethereum L1 so we can assume that this ordering is available to EVM
  • Espresso Sequencer blocks include a PoS agreement on the latest finalized Ethereum L1 block’s hash and height
  • Espresso Sequencer block ordering “finalization” is pretty fast (sub 5 seconds)
  • Because the L1 block hash is committed together with the transactions for our VM, it’s possible for us to include it as metadata for the application to read during tx processing
  • Because we have a dehashing device (and hopefully the L1 preimage database), there is no reason why we can’t read the whole of Ethereum state within the app
  • If the application is happy with the economic security of the PoS agreement by Espresso Sequencer network blocks, then there’s no issue here in supporting Ethereum-based assets.

I understand there is convenience to be built on just the capability of reading Ethereum state from a hash, in a way that’s not alien to developers.

Being an appchain client on Ethereum and evaluating this chain is always the headache, but, in short:

  • We can retrieve blocks and transactions through the Espresso Sequencer commitments made to L1 relating to our VM that we need to process the transactions
  • We can then read the state of the appchain and understand what needs to be made available for the EVM

This just describes one variant of Espresso Sequencer setting. What I need to make clear is that appchains can choose to switch parameters over time (and that involves a form of governance, we aren’t going straight to autonomous here). There may be other variants which include other methods of getting L1 block hashes - ranging from restaking, sync committees, node agreement based on posted Espresso Commitments, and other emerging methods. etc. It’s all about picking your level of confidence.

At least I see it entirely possible to bridge information in and out from Ethereum within Q1/Q2 but naturally there’s tradeoffs in choices. What I see as important is that appchains can progressively improve their security.

1 Like
13

Hey there! Ok, got it. So, about bridging:

  1. No Ethereum assets in Lambada right now, ok!
  2. About the road you described to get there (hopefully by Q1/Q2!), I kind of missed the whole story about submitting claims (which I guess cannot be done every input, hence epochs) and then validating/disputing them. How do you see that?

I guess in general, I was puzzled by this sentence you wrote:

As appchains are sovereign, bridging messages into other machines (EVM, other Cartesi machines) is seen as running a client for the appchain within the VM of that chain and reading state of the appchain.

But having Ethereum read the state of the Cartesi Machine is quite hard! And that’s what Rollups is all about: the whole story of epochs, claims, fault proofs, and executing the exact RISC-V instruction of disagreement on-chain to find out who’s right and who’s wrong.

I’ll add some other comments in subsequent posts, but this one is the main thing I’d like to be sure that we’re on the same page.

2 Likes
14

I like the idea of posting the app state to IPFS! This obviously only makes sense with Lambda (or Lambada), when the state is separate from the app, and if done well I think clients will be able to download only part of the state too (e.g., a directory within the state).
Btw, have you been talking to @Diego about Lambda, or how we can converge efforts here? I didn’t see any comments of yours there.
.

15

About posting the app itself to IPFS: this is what Sunodo deploy is doing too! But Sunodo currently just wraps the whole thing and posts the machine snapshot directly, instead of posting a docker container that is loaded dynamically into a standard Ubuntu machine (btw, I don’t think this part of loading from IPFS can ever be disputable on-chain right?).
I’m not sure I get the reason for your approach, which seems more complicated to me. Maybe you’re thinking about “bare-metal advance requests” too? (as described in the Lambda entry, in “4. Backend scalability”)

(I intended the text below to be a separate comment, but the forum only allows me to post 3 consecutive msgs :stuck_out_tongue: )

All in all, do you see Rollups and Lambada converging? From my perspective, if we implement L1 pre-imaging (aka access to base layer state) via the dehashing device, then Rollups inputs become base layer blocks, as you suggested above. With Lambda, Rollups state after each input block could also be posted to IPFS, as you are proposing. And finally, to get side effects on L1 (such as asset withdrawals), we need claims and something like vouchers, which Rollups already implements.
If that’s what you have in mind, then I think we can achieve something very interesting in the short term! We could advertise a more flexible and modular-friendly approach from Lambada’s side (maybe with a more experimental tone), while we improve and converge the more production-ready Rollups side, adding in L1 pre-imaging and Lambda, and after that also reading inputs from Espresso, Celestia or other sources via the dehashing device. What do you think?

1 Like
16

tl;dr we’re able to deal with this and arbitration, it’s just all dehashing (Dehashing device is the datastore of IPFS)

Why so complicated?

Couple of things:

  • looking how things work elsewhere: base images in AWS Lambda occasionally get updated for security updates; so appchains may need updating and it’s kinda hard to do it with a machine image
  • easier ability to test how it works inside different base images and emulators/etc
  • GitHub - ipdr/ipdr: 🐋 IPFS-backed Docker Registry like approaches (or for OCI containers) – publishing a planetary docker registry
  • deterministic, ‘built in cartesi’ reproducible appchain containers in further iterations; published to IPDR like approaches
17

and if done well I think clients will be able to download only part of the state too (e.g., a directory within the state).

This is also useful for tx processing too fwiw - executions can be backed by a IPFS cluster in cloud environments and only get what it needs from IPFS for processing, than having to get it locally. Also deduplication comes for free.

That said, IPFS/IPLD is not only approach. With dehashing device we can do:

Btw, have you been talking to @Diego about Lambda , or how we can converge efforts here? I didn’t see any comments of yours there.

Bit embarrassing :hear_no_evil: but it’s first time I read that post! must have been hiding! Been assuming we’d discuss things on Lambda workgroup

18

All in all, do you see Rollups and Lambada converging

I see everything converging over 12 months into a Cartesi Computer, or Cartesi protocol, or whichever.

General idea: by all means let’s get different ways of getting inputs in these lambda functions. There’s no reason why we couldn’t have a EVM based sequencer smart contract we take inputs from, already today.

1 Like
19

Ok great! But just to make sure we’re on the same page, I believe reading inputs from a smart contract is not the issue, it’s “writing back” to an EVM that’s hard, as I mentioned in this post. Could you clarify what you think about that?

Specifically:

  1. No Ethereum assets in Lambada right now, ok!
  2. About the road you described to get there (hopefully by Q1/Q2!), I kind of missed the whole story about submitting claims (which I guess cannot be done every input, hence epochs) and then validating/disputing them. How do you see that?

I guess in general, I was puzzled by this sentence you wrote:

As appchains are sovereign, bridging messages into other machines (EVM, other Cartesi machines) is seen as running a client for the appchain within the VM of that chain and reading state of the appchain.

But having Ethereum read the state of the Cartesi Machine is quite hard! And that’s what Rollups is all about: the whole story of epochs, claims, fault proofs, and executing the exact RISC-V instruction of disagreement on-chain to find out who’s right and who’s wrong.

20

it’s “writing back” to an EVM that’s hard

Let me see if I can relay my thinking here, by setting up a scene in Q2:

  • RiscZero ZK proving with settleability with STARK to SNARK into Ethereum is fully open source and generally available
  • We’re post Eigenlayer launch. The norm of co-processing with high (restaked) crypto economic security is normal, and we probably have Cartesi as a co-processor available, or a WASM one, or whichever (get a large sample or quorum of an honest majority). Cartesi as a co-processor with Eigenlayer (separate from Rollups product track)
  • There’s reasonable DA infrastructure available such as Celestia or EigenDA or Espresso or Protodanksharding
  • We’re talking about 100,000’s of appchains of all sizes and shapes, not a few.

So we can generally assume that some subset of problems are no longer, for ‘instant’ computation, limited to the capabilities of the EVM or lack of expressability - we can at bare minimum assume ability to write reasonable Rust programs and prove the results to Ethereum. We can assume data amount is no longer a problem (block size limits). This gives us the ability to look at this topic with fresh eyes and perhaps do more useful computation relating to being a client “on” EVM.

Appchains (or app specific rollups or whatever name) will exist in a multi-appchain world. It’s not just only about proving to Ethereum L1 or L2. It’s about proving to each other, too. Appchains are like islands with many types of bridges/ferries between them. Also, for good measure: Lambada won’t prove anything but resulting CID – not machine state hash, to others. Machine state hash is a technical detail and offers near-zero value to most developers.

See how things look over in Cosmos: https://twitter.com/0xPajke/status/1742744018553807181 (also, I will expect someone to write that for Cartesi)

Classical, full-blown Ethereum optimistic rollup security is the epoch, claims, fraud proofs (Dave), and 7 days delay with ideally L1 DA.

Do 90% of our appchain use cases need that for their assets and bridges? Would they be perfectly fine with 20% of that security from a set of co-processors? Would it be better to add the fraud proof on co-processor slashing instead of on every single appchain?

The best way of finding that out is to create the ability to choose and grow as an appchain and progressively become more secure.

The short answer is:

We can do more than just classical security. And it’s a new world to understand how everything fits in a multi-appchain multi-bridge world. We’ll see Eigenlayer based bridges for even other blockchains (Filecoin, etc).

For most of our initial Lambada customers, they’d be perfectly happy with a sampling from something like Witness Chain to represent their state. In my humble opinion.

1 Like