Cardano Updates

TxSubmission is a pull-based protocol — the server goroutine calls
RequestTxIds to pull transactions from the peer, so it inherently
controls the pace. Rate limiting after the pull was pointless for
network protection and actively harmful: under load, the limiter
rejected batches already received, creating a tight retry loop that
starved chainsync/blockfetch of CPU (20 peers × rate limit checks =
CPU death, BP fell 20 blocks behind on preview).

The natural rate limit is the processing time of RequestTxs +
mempool.AddTransaction. The mempool handles dedup internally.

This reverts ae017a4 and subsequent backoff fixes.

Signed-off-by: wcatz <[email protected]>

Decode the exact transaction CBOR from preview-net slot 107726771
(tx 02eb5d86...529138) — a CIP-68 NFT script deployment with a
ScriptDataHash, 1 witness datum, and 0 redeemers — and verify that
UtxoValidateRedeemerAndScriptWitnesses does not reject it.

Signed-off-by: wcatz <[email protected]>

Signed-off-by: William Hankins <[email protected]>

Signed-off-by: William Hankins <[email protected]>

The TxSubmission server goroutine entered a tight wait-retry loop when
rate-limited under mempool flooding, starving chainsync/blockfetch of
CPU. With 20+ peers this caused the BP to fall 20 blocks behind tip.

Add exponential backoff (150ms base, 5s cap) with a reused time.Timer
to eliminate GC pressure. After 3 consecutive rate limit hits, drop
the offered TxIds and return to blocking on RequestTxIds — the peer
will re-offer them, and the goroutine parks at zero CPU. Log only the
1st hit and every 10th to reduce log noise from 60 lines/sec to ~6.

Replace sync.Mutex + map with sync.Map in the rate limiter for
lock-free reads on the hot path (existing peers).

Signed-off-by: wcatz <[email protected]>

UtxoValidateRedeemerAndScriptWitnesses rejected transactions that carry
a ScriptDataHash but have no redeemers, even when witness datums are
present. Per the Cardano ledger spec the script data hash covers
redeemers, witness datums, and cost models — so a transaction that
provides datum pre-images (e.g. a script deployment TX) without
executing any scripts is valid.

This caused all preview-net nodes running gouroboros validation to halt
at slot 107726771 (tx 02eb5d86...529138).

Signed-off-by: wcatz <[email protected]>

The new `ConformanceTest` record contains fields for all data formerly used
to run a test via `forAllGenesisTest` helper, plus other fields that pertain
to its evaluation as a test property on a`TestTree`.
A value of this type is defined for each point-schedule/genesis test.

All such `ConformanceTest`s are arranged in a `TestSuite`s, a data
structure introduced with the goal of eventually exporting them as
part of a new sublibrary for the Conformance Testing of Consensus harness
(see https://github.com/tweag/cardano-conformance-testing-of-consensus).
This data structure is designed to optimize single test lookups,
while retaining the necessary structure to be compiled back to a `TestTree`,
so that the introduced changes preserve the semantics of the
`ouroboros-consensus:test:consensus-diffusion-test` test suite.

To accomplish this, a new data type is introduced in each module as a `key`
for the locally defined `TestSuite`, such that each test in the module
corresponds to a unique value (nullary constructor) of this type. This means
that including a new test in a `TestSuite` requires the extension of such key
type by introducing a new data constructor. These `key` types are aggregated
into higher level key types to reify the nested grouping of the original
tasty `TestTree`s. It is by means of `mkTestSuite` and `at` that a higher
level `TestSuite` can be defined. The `SmallKey key` constraint is needed for
their exhaustive construction, via `newTestSuite` and `mkTestSuite`; as
implemented, a `TestSuite` is a total map.

Co-authored-by: Sandy Maguire <[email protected]>