Cardano Updates

instead of the removed cexplorer retriever

These methods are purely for convenience, but may not be really
needed (depending on application) because the aggregate key can just be
used normally using verifyDSIGN

Also move aggregateVerKeysDSIGN out of DSIGNAggregatable.

Apply `wasm-opt` to wasm generated in CI

* feat: Master-builder image

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Init workflow

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Remove builder workflow from my feature branch

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Change builder workflow

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Clean up

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Fix

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Try to push

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Small improvements

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Debug

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Debug

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Fix empty line

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Test Trivy

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Revert

Signed-off-by: Evgeniy Dikevich <[email protected]>

* Schedule build

Signed-off-by: Evgeniy Dikevich <[email protected]>

---------

Signed-off-by: Evgeniy Dikevich <[email protected]>
Co-authored-by: Oleksandr Prokhorenko <[email protected]>

This PR implements the Peras voting rules in a pure fashion. That is,
given a PerasVotingView (which needs to be constructed in an impure
context), they determine purely if a node is allowed to vote or not in a
given round w.r.t. the voting rules from the CIP-0140. See:

https://github.com/cardano-foundation/CIPs/blob/master/CIP-0140/README.md#rules-for-voting-in-a-round

(Note that this is orthogonal from the committee selection: both
conditions need to be satisfied before a node is able to cast a vote in
a give round.)

Notably, our implementation needs to cover the somewhat special case of
deciding whether to start voting at genesis. The problem arises due to
the lack of a latestCertSeen to enable the "voting path" of the rules.
While the CIP uses a specially-defined cert0, our implementation encodes
this case via nullable certificate behind a WithOrigin.

In addition, this PR implements conformance tests against a simpler model
implemented directly over Bools. In the future, this model could be
reified from the Agda spec. Notably, we need to remark that, because VR-1A
is evaluated first, then:

  * VR-1A => !VR-2A

So, this case can't be covered by the test suite in a consistent way.
To hopefully convince you of this, we can show that VR-1A~True and
VR-2A~True leads to a contradiction. Using the following definitions:

  * r: current round (>=0)
  * C: round of the latest certificate seen (>=0)
  * R: Peras ignorance rounds (>0)

We have:

  * VR-1A := r + 1 == C
  * VR-2A := C + R <= r

If we replace C from VR-1A into VR-2A, we get:

  * r + 1 + R <= r

Since R>0:

  * 1 + R > 1

Therefore, we have:

  * r + 1 + R > r + 1 > r

And we conclude that:

  * C + R > r

Thus, !VR-2A, which is a contradiction.

With this in mind, the currently selected generation sizes and frequencies
lead to the following coverage of our testing property:

ouroboros-consensus
  Peras
    Peras voting rules
      isPerasVotingAllowed: OK (0.45s)
        +++ OK, passed 100000 tests.

        Actual result (100000 in total):
        33.708% VoteReason(VR-2A and VR-2B)
        32.242% NoVoteReason(VR-1A or VR-2B)
        30.538% NoVoteReason(VR-1A or VR-2A)
         1.871% VoteReason(VR-1A and VR-1B)
         1.641% NoVoteReason(VR-1B or VR-2A)

        Should vote according to model (100000 in total):
        64.421% False
        35.579% True

        VR-(1A|1B|2A|2B) (100000 in total):
        19.213% (False,True,True,True)
        18.595% (False,True,True,False)
        14.495% (False,False,True,True)
        13.647% (False,False,True,False)
         7.992% (False,True,False,False)
         7.835% (False,False,False,False)
         7.365% (False,False,False,True)
         7.346% (False,True,False,True)
         1.017% (True,True,False,False)
         0.860% (True,False,False,False)
         0.854% (True,True,False,True)
         0.781% (True,False,False,True)

        VR-1A (100000 in total):
        96.488% False
         3.512% True

        VR-1B (100000 in total):
        55.017% True
        44.983% False

        VR-2A (100000 in total):
        65.950% True
        34.050% False

        VR-2B (100000 in total):
        50.054% True
        49.946% False

Co-authored-by: Agustin Mista <[email protected]>
Co-authored-by: Alexander Esgen <[email protected]>
Co-authored-by: Georgy Lukyanov <[email protected]>
Co-authored-by: Thomas BAGREL <[email protected]>
Co-authored-by: Nicolas BACQUEY <[email protected]>

Co-authored-by: Agustin Mista <[email protected]>
Co-authored-by: Alexander Esgen <[email protected]>
Co-authored-by: Georgy Lukyanov <[email protected]>
Co-authored-by: Thomas BAGREL <[email protected]>
Co-authored-by: Nicolas BACQUEY <[email protected]>

updated next js to 15.5.9

updated next js to 15.5.9

This was resolving an issue where (likely for another reason), rapidly
submitted transactions required re-enqeueing of ReqTx inputs.

Hypothesis: When the input queue was not bounded, another bounded
queue (in Hydra.Logging) was creating delays leading to the re-enqeued
retrying of applying transactions start to fail (because they time out).

It is not known why the chain of transactions we used (see hydra-cluster
bench) was even requiring the re-enqeuing in the first place though.

From https://github.com/tweag/cardano-cls at 8189149495f68c70ab5ad6ddcbe11b4b60431777

From https://github.com/tweag/cardano-cls at 8189149495f68c70ab5ad6ddcbe11b4b60431777