Blocks from the future​

We identified two issues relating to "blocks from the future".

1. Blocks from the near future
2. Blocks from the far future

While blocks from the near future have been known to occur on mainnet as a result of clock skew/misconfiguration, there are no known instances on mainnet of blocks from the far future. In both cases, restarting an affected node would resolve the issue.

What is meant by a Block from the Future?​

A node considers a block to be from the future if its slot is ahead of the current slot. Ouroboros Praos mandates that all chains containing blocks from the future (at that time) are ignored during chain selection. As Praos assumes that all nodes have access to perfectly synchronized clocks, this will never cause nodes to disregard blocks that have been minted by other honest nodes. In an actual real-world deployment, this assumption is unrealistic due to the imperfections of protocols like NTP as well as leap seconds.

The issues that were identified meant that blocks from the future could potentially be used by malicious actors to create denial-of-service attacks.

Both issues were fixed by Cardano node 8.8 or later, and were eradicated at the Chang hard fork.

Further Details​

Report on Blocks from the Near Future

Report on Blocks from the Far Future

High level summary​

The SRE team continues work on Cardano environment improvements and general maintenance.

Some notable recent changes, updates or improvements include:

• Mainnet was hard forked to Conway era!

• Legacy mainnet relays from cardano-ops cluster were stopped and retired.

• Legacy cardano-explorer hosted at explorer.cardano.org was retired with landing page and beta explorer services now provided by Cardano Foundation.

• Cardano-smash production load was cutover from the legacy cardano-world cluster to the replacement cardano-mainnet cluster. Remaining cardano-world resources will be retired in the near future.

• Cardano-faucet was updated for cardano-node 9.1.x level compatibility.

Repository Work​

Cardano Faucet​

• Brings faucet up to cardano-api and cardano-cli level of cardano-node 9.1: bumps relevant flake pins, updates CHaP indexes, applies fixes for upstream breaking changes, removes cardano-addresses srp, adjusts ghc options, fixes ming32 CI builds, applies most hlint and fourmolu style and config suggestions respectively: cardano-faucet-pull-12

Cardano Parts​

• Sets cardano-node to 9.1.1, cardano-db-sync to 13.5.0.2, cardano-faucet to 9.1. Adds alerts, dashboard fixes, nixos iowait optimization, smash and blockperf nixosModule improvements. More detail is available in the PR description: cardano-parts-pull-47

Cardano-mainnet​

• Deploys cardano node to 9.1.1, cardano-db-sync to 13.5.0.2. Improves smash deployments and backup role for production load handling. Improvements made in cardano-parts PR#47 are included in this PR. More detail is available in the PR description: cardano-mainnet-pull-21

Cardano-playground​

• Deploys cardano node to 9.1.1, cardano-db-sync to 13.5.0.2, cardano-faucet to 9.1. Tests RTS parameter optimization and tracing system changes on preview network machines, tests utxo-hd-9.1.1 on mainnet edge nodes. Improvements made in cardano-parts PR#47 are included in this PR. More detail is available in the PR description: cardano-playground-pull-31

Cardano-world​

• Destroy retired legacy explorer metal machines and disable alerting: commit-compare

High level summary​

• Added a snapshot-converter tool, which will be merged soon. This tool converts non-UTXO-HD ledger snapshots, into UTXO-HD ones, so that the user does not have to replay from Genesis when using an UTXO-HD capable node. This patch also solves an issue with deserialization of TxOuts in Conway in the UTxO-HD implementation.
• Solved a memory leak in the UTxO-HD implementation. This patch will be benchmarked this week.
• Wrote a test for adding large txs to the mempool.
• Expanded the Mempool capacity beyond just byte size.
• @amesgen discovered and advised on a Conway ledger snapshot deserialization bug.

High level overview​

The Mithril team kept working on decentralizing the signature orchestration of the Mithril network. In this preliminary phase, they began implementing a buffer store for individual signatures that may arrive before being processed by an aggregator. Additionally, they moved the broadcast of signer registrations to the aggregator’s epoch settings route. The team also monitored the Chang upgrade to ensure the Mithril networks operated correctly and cleaned up unnecessary code. Additionally, they implemented a seamless transition from unstable to stable features in the WASM client.

Finally, the team activated a feature allowing the selection of the arithmetic backend used by Mithril cryptography in the client and refactored the organization of signer dependencies.

Low level overview​

• Completed the issue Follow up the Chang hard fork #1910
• Completed the issue Aggregator exposes Cardano transactions signing configuration #1898
• Completed the issue Optimize memory usage of signer for Cardano transactions #1903
• Completed the issue Add message signed in signature HTTP messages #1899
• Completed the issue Cargo Deny complains about LGPL-3.0 licenses #1786
• Completed the issue Reorganize signer dependencies #1906
• Worked on the issue Aggregator buffers signatures for unknown open message #1900
• Worked on the issue Signer retrieves registrations with epoch settings route #1897
• Worked on the issue Seamless transition of features from unstable to stable in client WASM #1911
• Worked on the issue Test Cardano transaction chain rollbacks #1840

High-level summary​

We have put together a nice base of network-resiliance tests to build from, and already started exploring potential improvements to our networking. We've made good progress on incremental commits, by way of deposits, and settled on an approach to tackle a few of the known problems related to "stuck funds", and finally we completed some work related to usability of new functionality and documentation in our changelog. Up next we will switch the ledger to Conway and prepare a release, and we will continue working on incremental commits.

What did the team achieve?​

• Implemented initial suite of network-resiliance tests #1532
• We explored persistence as an improvement to our networking layer #1593
• Incremental commits (coming in a 0.19 release) have pivoted to a deposit-based scheme based on open discussions (thanks @GeorgeFlerovsky!)
• Settled on Partial Fanout as a good solution to a few known problems
• Split out some functionality into a new library, hydra-tx, to eventually support user workflows around deposit/recover transactions #1587
• Golden tests to help track breaking data changes in the changelog #1554

What's next?​

• Switch ledger to Conway #1178
• Update our networking page with the findings from our resiliance work
• Fix search on the docs #1556
• Release 0.19.0 with L2 Ledger in Conway
• Continued work on incremental commit #199