Hide dataAvailability

[tuler]

I found this dataAvailability API for instantiation of new applications very confusing and counter intuitive, despite the flexibility it provides.

A simpler API would be to hide the dataAvailability param in a factory for InputBox only, and a factory for Espresso applications. I actually think it should be even simpler than that, and honestly it smells over-engineering, but I don't have the entire context to argue that, it's just a feeling.

I'm not suggesting we merge this PR, it's mostly to explain my point.

[pedroargento]

Do we need new Factories or could we add new functions in the ApplicationFactory for each DataAvailability?

[tuler]

I thought the motivation of the generic bytes dataAvailability was to allow future DAs without changing the factory. If you have a single factory with two methods you will need to change it to add a third.

[pedroargento]

I thought the motivation of the generic bytes dataAvailability was to allow future DAs without changing the factory. If you have a single factory with two methods you will need to change it to add a third.

Was just editing my comment with this point: It would indeed be weird if we decide to include more options in the future, if we chose to hide them with new factories. But it would still allow for flexibility for any DA, they would just be un-hidden.

If a new DA becomes really relevant and a lot of people are using it we can discuss hiding the parameter with a new factory.

[tuler]

I think the key point is that this over generalization only makes sense when clients are able to handle them in a general way.

If clients need to handle each case differently, and that's the case for the rollups-node and the CLI AFAIK (not sure about Dave, but probably so), then the generalization is worthless, and you are better off with a tailored case A and a tailored case B.

[guidanoli]

I get the sentiment, and I would much prefer the ERC-165 approach.

However, if you want to avoid having to encode the DA blob off-chain, we can provide contracts that do that on-chain, so that you can just eth_call them. One possible interface would be this:

interface DataAvailabilityEncoder {
    function encodeInputBoxDataAvailability()
        external
        view
        returns (bytes memory);

    function encodeInputBoxAndEspressoDataAvailability
    (
        uint256 fromBlock,
        uint32 namespaceId
    )
        external
        view
        returns (bytes memory);
}

If we create a factory for every possible config, we are going to blow up the number of factories into combinatorial madness. We have the vanilla application factory, the self-hosted application factory, and now we would have to have two more factories for each DA config...

[tuler]

we are going to blow up the number of factories into combinatorial madness.

The combinatorial madness is there anyway, you are just throwing it to the client.

[guidanoli]

The combinatorial madness is there anyway, you are just throwing it to the client.

Naturally, the client would have to allow the user to select one from multiple DAs and consensus models. However, on-chain we wouldn't necessarily have multiple factories for each combination.