On-chain node configuration

[guidanoli]

No description provided.

[miltonjonat]

Not sure InputBoxAndEspresso should be part of a global official DataAvailability interface. I am expecting people to be able to add their own without messing with our contracts.

[guidanoli]

I think it's good to have at least the ones we fully support defined here so that deployment front-ends and the node can utilize the same definitions. :-)

[guidanoli]

People can still provide their own DA config blobs on deployment, and hack their own DA provider node plug-in that understands and decodes that blob.

[guidanoli]

Also, if someone wants to add a new DA signature, they can just open a PR. It won't affect the bytecode of our deployed contracts, and therefore won't trigger any redeployments. Therefore, we can release minor versions with these changes.

[miltonjonat]

Hmm I see. But "fully supporting" an integration is a complicated term, and I'm still not very comfortable with our regular contracts mentioning specific integrations/extensions, I feel it should be separate. Couldn't these signatures be placed in separate interfaces?
I'd like to hear other opinions, maybe @pedroargento or @tuler?

[guidanoli]

We could totally place these definitions in a third place, but it is convenient to place them here because the rollups-node repo already uses the artifacts from rollups-contracts (which includes contracts/interface ABIs), and front-ends often depend on the @cartesi/rollups npm package to interact with our contracts (e.g. when deploying).

[guidanoli]

But yeah, we could create a new repo (e.g. rollups-da-config) with just this file, which would not be imported by rollups-contracts, but would be imported/used by the node and deployment front-ends.

[guidanoli]

I'm still not very comfortable with our regular contracts mentioning specific integrations/extensions

Our regular contracts are not mentioning integrations/extensions. If you were to draw a dependency graph of the rollups-contracts with this PR, this interface would be isolated from every other contract. It would not be referenced by any other contract, and therefore not influence any of them. That's why we could, in theory, move it to a separate repo.

[guidanoli]

Just to be clear that I'm not advocating to moving it to somewhere else. I think it's okay to keep it here. If this interface grows out of control, we can think about create a dedicated repo for it.

[tuler]

why bytes?

[tuler]

I mean, why not a ERC-165 contract?

[guidanoli]

Because with bytes we can encode more data specific to that application.
For example, applications that use Espresso would specify their namespace and Espresso block height.

[tuler]

I'm not a solidity dev to judge this well.
But it feels very weird this generic bytes field, when what you have is polymorphism.

In a sane language, which I guess it not solidity, I'd expect a usage like:

IDataAvailability da = app.getDataAvailability();
if (da instanceof IEspressoDataAvailability) {
  IEspressoDataAvailability eda = (IEspressoDataAvailability) da;
  eda.getFromBlock();
  eda.getNamespaceId();
}

[guidanoli]

Yes, this solution could work, but then you would have to deploy this data availability contract for every application that uses Espresso. In reality, we don't need polymorphism. We only need algebraic data types, as in Haskell or Rust:

enum DataAvailabilityConfig {
  InputBox { inputBoxContract: Address },
  InputBoxAndEspresso { inputBoxContract: Address, fromBlock: Uint256, namespaceId: Uint32 },
}

The way we are encoding algebraic data types in Solidity is as ABI-encoded function calls.

[tuler]

The way we are encoding algebraic data types in Solidity is as ABI-encoded function calls.

You have to agree that is a very non-idiomatic way of expressing algebraic types. 😵‍💫

[guidanoli]

You have to agree that is a very non-idiomatic way of expressing algebraic types. 😵‍💫

Unfortunately, that is the best way I know of expressing algebraic types in Solidity.