chore(contracts): Add binding check

[ethenotethan]

Why are these changes needed?

Adds a hygiene workflow which ensures that abi artifacts must be reflective of latest contract changes. Also noticed we were using two compilation commands (compile-el, compile-dl); these don't appear to have any instrumentation over the compile.sh script behavior so condensed into single compile-contracts target 😄

Checks

• I've made sure the tests are passing. Note that there might be a few flaky tests, in that case, please comment that they are not relevant.
• I've checked the new test coverage and the coverage percentage didn't drop.
• Testing Strategy
  • Unit tests
  • Integration tests
  • This PR is not tested :(

[litt3]

Would this run in CI then?

If so, why have the bindings committed to the repo at all, if we generate them in CI?

[samlaf]

the CI is just recreating the bindings and making sure that no new artifacts are created (by making sure git status is clean). If it fails it reminds the PR creator that they forgot to update the bindings

[litt3]

It's not something to address for this PR, but my point is that I don't think we should have generated files checked into git at all. CI should generate, and local builds should also generate. Tracking via git is just clutter

[ethenotethan]

@litt3 How would package artifacts be importable under this model? iiuc this would make EigenDA entirely self contained. Also generating them once ensures that everyone is pinned to the same code.

[litt3]

How would package artifacts be importable under this model?

The files would be generated as part of the build process- so they would be importable just like they currently are, after doing a build. And if any local changes were to be made to the contracts, then the locally generated artifacts would be updated during the next build execution.

Also generating them once ensures that everyone is pinned to the same code.

Is the concern here that the artifact generation might not be deterministic? If we do trust the determinism of the generation, then we are guaranteed that everyone is using the same generated artifacts, as long as they are using the same source files.

I suppose committing the generated files to git provides a check that the CI artifact generation precisely matches the artifact generation of the development machine used to commit the files to git. This doesn't seem like the most robust mechanism to test deterministic generation, though.

[jianoaix]

I find it useful to view generate golang code, e.g. you could see clearly what's the function signature in golang is like when making a call.

[litt3]

With my proposed strategy, you would still be able to view the generated golang code. Everything would be exactly the same on disk, the only thing that would change is what's committed to git

[jianoaix]

The use case is code viewing on github

[jianoaix]

The PR lgtm, but i think we had some discussion before regarding if requiring the latest version of binding, if anyone remembers it, may bring the context here so we make sure this is what we decided to go