Media Application

🙏 Help and Support
1

Hi everyone

I’m the founder of this media project. We recently came out of stealth after quite some time spent at mechanism design. Eg we built an entirely novel market based on Bayesian Truth Serum to gauge the quality of opinion articles that we’re particularly proud of. We’re now investigating the various options of where to build and are very impressed with the Starknet ecosystem.

We’re an app and want to focus on making it as successful as possible. The less we have to focus on building infrastructure, the more we can focus on that goal. So we’re trying to outsource as many things as possible to stuff that’s already built. We don’t want to build our own L1 or our own DID or PoP protocol, etc, etc. Not just from a development perspective but also from the perspective of having to get L1s supported by CEXs, etc, etc. These things take a lot of time and energy and they’re not core to what we’re trying to do. So long story, short, the likes of Starknet is a natural place to build.

The revenue model of the app will rely heavily on micropayments so we’re an extremely fee sensitive app. From my research of Starknet, to achieve our goals under the assumption that usage of Starknet is going to be a lot higher than it is now in two years time, we’re either going to have to rely on volitions or spin up our own L3. The volitions integration timeline is a little uncertain but we’re not going to launch for some time so this is probably not going to be an issue.

I have a few questions regarding both these possible routes.

  1. When volitions are implemented will contracts that use different DA solutions to each other lose syncrhonous composability on Starknet (this is not a big deal to us BTW I’m just curious)

  2. If we spin up our own L3 can we abstract it away from the user by either employing a bridge that permits synchronous composability (ZK Sync claims to allow this with ZK Porter shards) or at the wallet level using account abstraction and relayers? We really want to avoid having our users manually bridge across from Starknet as the UX of bridges is simply not suitable for the masses in our view.

  3. Would anyone be able to provide a rough estimate of the TX fee differences between using a L3 over Starknet and volitions on Starknet directly assuming the same DA layer is used? Second part of this question if we were to use relayers from L2 to L3 for each TX (assuming this is even possible) do any cost advantages it might have evaporate?

If anyone had any insights here they’d be greatly appreciated.

2

Very interesting! Appreciate the project mission and enjoyed reading the post on “academic publishing”. I’m not a core dev so take my input with a dose of salt.

Supposing trustless bridging is not a requirement and you’re OK with some trust assumptions, I suspect you can get L3/L2 sync composability (assuming what’s needed is two-way calls and exchange of input/output from transaction execution across the L3/L2) but see that as being quite technically challenging. Gonna look into ZK Porter, this is just based on my broad understanding of interoperability across decentralized domains.

Really curious to understand better why is synchronous composability needed? Would something like IBC protocol fit the bill (I’m exploring support for that in Starknet). IBC is essentially message passing (as opposed to the “shared memory” model of sync. comp.). Is it just for token bridging or other type of applications? Any insight appreciated!

3

We don’t necessarily need synchronous, but it’s obviously faster than async. Our main concern is that bridging is completely abstracted away so any interactions with Starknet or other Starknet appchains are the same as transacting on our own chain. I’m thinking of the masses here. Bridging is horrible.

Zk Sync just introduced this yesterday. I think Starknet will have to deploy something like this. I’m told it will.

4

I agree bridging is horrible—as a blanket statement. And I would add it depends a lot on application design and needs. Some applications manage to be quite successful without synchronous composability. In time most apps will need to specialize sufficiently so they offer a compelling value proposition with or w/out sync. comp. in my opinion. Anyway, I was trying to gather requirements and see if IBC could work for your needs. Potentially not?