Skip to main content

· 3 min read
Michael Karg

High level summary

  • Benchmarking: We've performed and analysed feature benchmarks for both UTxO-HD and the current P2P stack.
  • Infrastructure: Various improvements of our analysis pipeline have been merged to master, supporting safe log truncation.
  • Tracing: Namespace consistency checks have been merged to master along with a curated configuration for benchmarking.
  • Nomad backend: We're productively using the new backend to measure new vs. legacy tracing system, adding many quality-of-life improvements.

Low level overview

Benchmarking

We've completed various runs and analyses targeting two distinct features of the node: UTxO-HD and Peer2Peer.

With our UTxO-HD benchmark we could clearly localize one point where this new way of maintaining ledger state is still costly, but at the same time confirm that in basically all other aspects UTxO-HD makes no difference in performance.

The Peer2Peer benchmarks focused on the effects that enabling this feature on a block producing node has on propagation times, as well as scrutinized a proposed change to the Peer2Peer network stack.

Infrastructure

As a result of optimizing in-memory representation of log objects, which are constructed from a node's traces, we can now analyse runs that last longer in total. For runs that exceed their expected duration, analysis now supports a truncation operation that keeps the interdependencies of block events intact.

Truncation might happen at a slightly different point in time - and therefore in its log object stream - for each node in the cluster. An additional step validating the block hash timeline of the cluster has been implemented for the pipeline. It provides early feedback on whether a specific truncation will lead to a valid full analysis, which requires much more time.

Tracing

Consistency checking of namespace implementation and configuration when using the new system has been completed. This feature enables feedback on when tracer implementation details in some component might have changed. It's also able to detect when a configuration used for operating a cardano-node shows inconsistencies with the namespaces the system provides - and hence needs attention.

Furthermore, we've created a fine-grained configuration of the new system that caters to benchmarking's need of very many detailed trace messages. It's aimed at mirroring the same amount of trace messages, and information, we're seeing from our usage of the legacy system; an important step in making benchmarks between systems comparable.

Nomad backend

The new backend is currently being used for further validation with regard to the existing cluster. Additionally, we're using it in production mode to comparatively benchmark both tracing systems after merging past month's optimizations - which is the first real-life application of the nomad cluster. Hands-on experience in that phase translates into many small improvements which can be immediately applied to enhance user experience for the new backend.

· 3 min read
Damian Nadales

High level summary

We were able to successfully run the system-level benchmarks for the UTxO-HD implementation, for the first time. There was an important regression in block forging performance that will have to be addressed before UTxO-HD is released. We also revisited the implementation of our query processing logic, which was needed to address the performance regression found in the query-by-address command. The preliminary performance results show that now the performance of this query is on-par with the Cardano baseline version, but we need further confirmation. On the Genesis front, we presented the grinding-aware safety argument for the proposed historical Cardano Genesis windows to the IOG Researchers. The Consensus release engineer finished his rotation: version 8.3.0-pre of cardano-node is releasing 2023 September 5.

UTxO-HD

  • We ran the first successful system-level benchmarks for UTxO-HD (see #203) using the in-memory backend.
    • We observed a factor 12 regression in the forging performance, which we will have to address. There are strong indications that the regression is due to the backing store accesses that take place when taking a mempool snapshot.
    • After the mempool regression is fixed the benchmarks need to be ran again.
    • System-level UTxO-HD benchmarks with the LMDB are still pending.
  • UTxO-HD will eventually be necessary due to the growth of the UTxO set and other ledger state structures that live in memory at the moment. However, we are trying a strategy by which we could preserve the baseline performance of the node, in case SPOs and other node users are not ready to migrate yet (see #344).
  • We implemented a new way of processing queries at the hard-fork block level, which resolves the performance regression observed in GetUTxOByAddress (see this comment). Preliminary results are promising.
  • Regarding the roll out plan, UTxO-HD requires a significant change in the Consensus codebase. Even though we might be able to hide any potential performance impact in the node by keeping all data in memory (#344), the Consensus component was significantly changed, so we might have to postpone releasing this feature to mitigate any risks of conflicting with the implementation of CIP-1694 and release of Conway.

Tech debt

  • We added tests that Consensus emits valid CBOR (#3099). This helped us detect a couple of serialization bugs. The tests still need to be merged into the main branch (#323).

Support

  • Nick Frisby finished his release engineer rotation; cardano-node 8.3.0-pre is releasing 2023 September 5.
  • We helped to investigate a protocol version bug in Sanchonet (see #3491).
  • We started to implement the Network interface for bootstrap peer functionality, from which Genesis will benefit as well (see #91.

· One min read
James Chapman

The team works on applied research and consulting in formal methods that is directly applicable to evidence based engineering in Core Tech and beyond.

High level summary

The team is currently formalising mini protocols and also further developing the performance modelling prototype.

Details

  • finalising a presenting performance analysis internship work to the formal methods team

  • developed a new Isabelle mini-protocol framework and examples

  • planning an extended version of the ICE DeltaQ paper

  • working on algebraic rules for properisation of any-to-finish

· One min read
Sasha Bogicevic

High-level summary

This week, the Hydra team focused primarily on changes needed in the network layer and have the first draft document related to needed design. They also improved the user experience by allowing a commit using inline datums. Discussed the off-chain governance with researchers and improved internal model tests.

What did the team achieve this week

  • Monthly report published
  • Small changes to hydraw and tutorial in light of the Masterclass
  • Investigated a bug and saw it was solved by recent developments
  • Improved the model tests by fully validating L1 transactions
  • Enhanced the /commit API to also allow commit from scripts with inline datums (user request)
  • Discussed off-chain governance with IOG and CF researchers
  • Drafted a first network specification document in the context of Network resilience

What are the goals of next week

  • Have a clear understanding of the changes we need for the "Improve network resiliency" feature
  • Groomed and agreed plan on incremental commits/decommits
  • Updated tutorials including CI workflows to check consistency
  • Update to GHC 9.6 and latest cardano dependencies (ledger/plutus)

· 2 min read
Alexey Kuleshevich

High level summary

Broadly speaking the Ledger team focused on a few main areas of Conway era:

  • Creation of voting state snapshots in order to correctly delay ratification for one epoch
  • Validation of the Governance Actions sequencing and ordering
  • Proper expiry of DReps and Proposal Procedures
  • Expanding Conway Genesis functionality
  • Utilization of some of the new Protocol Parameters in ledger validation rules

Low level summary

Conway era

  • pull-3659 - Validate Network for ProposalProcedure and TreasuryWithdrawal
  • pull-3637 - Avoid using sequence of tuples, by adding GovActionId to GovActionState
  • pull-3651 - Inactive DReps
  • pull-3664 - Track proposal expiry
  • pull-3668 - Add min committee size predicate to NewCommittee
  • pull-3669 - Add Proposal deposit check against PParam
  • pull-3676 - Fix inactive PoolStake not counting as Drep Stake
  • pull-3635 - Make snapshots of GovActionsState
  • pull-3670 - Validate previously enacted govAction
  • pull-3694 - Improve error reporting on the positive coin decoder
  • pull-3674 - Added RATIFY thresholds
  • pull-3684 - Add proposal delaying, remove predicate failure from ENACT
  • pull-3688 - DRep Refunds and update evalTransactionBalance

Improvements and releasing

  • pull-3677 - Minor patch that fixes the DRep distribution computation
  • pull-3686 - Post patch release fixup
  • pull-3695 - Changelog for cardano-node-8.3 release
  • pull-3683 - Add two new bench mark programs

Testing