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.

[miltonjonat]

@guidanoli @pedroargento so what's the conclusion here? Are we doing something with ERC-165 in the end, or sticking with bytes? We need to move on this one really soon, since the initial Node v2 release will use this.
@vfusco FYI

[guidanoli]

Hey Milton, you're right.
We should decide which strategy are we using.
I'm personally leaning towards ERC-165, because of its elegance and cost.
Let's wait and see what @pedroargento, @ZzzzHui and @vfusco think as well.

[ZzzzHui]

I side with Pedro that this solution is more straightforward than the ERC165 one

[miltonjonat]

I've talked to @vfusco and he is a bit concerned about the impact of the ERC-165 solution on the current Node's code. It is mandatory for us to release a Node version in the coming weeks, and it would be really important to include some on-chain config solution.
So on our side, we are leaning towards this solution as well, at least for the time being. We could consider the ERC-165 one at a later time, when contracts are again updated due to Dave etc.

[guidanoli]

Alright, having seen that the majority prefers the ABI-encoded function call, let's move with this solution.