Release of Cardano-node 8.3.0-pre for SanchoNet. Adds DReps to the Conway governance rules. Allows registration of DReps, delegation to DReps and voting on constitution action with DReps and SPOs. This release completes phase 2 of SanchoNet feature roll out plan
CLI continues on its migration to a era-based top-level commands. This sprint we moved text-view, key, query, genesis, node, stake-address, transaction and address into this new command structure. This is the initial migration, there is still some clean-up to do on future sprints.
We are moving the drep delegation-certificate to the stake-address command so delegating to a drep is done via stake-addres vote-delegation-certificate. Along the same lines, we are renaming
stake-address delegation-certificate (delagating to a stake pool) to stake-address stake-delegation-certificate to distinguish between stake delegation to a pool and votes delegation to a drep. On top
of that, there is a new type of delegation certificate to delegate (stake) to a stake pool and (votes) to a drep simultaneosuly stake-address stake-and-vote-delegation-certificate. Note that change is not included on 8.3 but will come on 8.4.
Removing --conway-era flag from all the transaction sub-commands.
Update description fields in delegation certificates from Stake Address Delegation Certificate to respectively (Conway onwards):
Stake Delegation CertificateVote Delegation CertificateStake and Vote Delegation Certificatestake-address vote-delegation-certificate commandstake-address stake-and-vote-delegation-certificate commandTreasuryWithdrawalCmd to a recordstake-address stake-delegation-certificate command across erasEraBased prefix and add Cmd suffixaddress commandsstake-pool command related types, functions and modulesredundant-constraints warning only on ghc-8.10.7EraBased prefix from era-based commandsdelegation-certificate to stake-delegation-certificate only in era-based command structurenode run commands implementation into era basedstake-address command groupFeatureInEra ShelleyBasedEra instanceEraBased prefix from errorstext-view run commands implementation into era-basedkey run commands implementation into era basedquery run commands implementation into era basedgenesis run commands implementation into era basedpool run commands implementation into era basedstake-address run commands implementation into era basedaddress run command implementation into era-basedconway governance commandskey-period-infohprop_golden_shelleyStakeAddressRegistrationCertificateWithBuildRaw testcaseShelleyToBabbageAndConwayEraOnwards functionFeatureInEra instances for CardanoEra and ShelleyBasedEramapSomeAddressVerification key functionqueryGenesisParameters so that it can be queried in any era
This week, the Hydra team improved the commit process with support for inline datums. They simplified the chain layer by refactoring how the chain state is persisted. Updates to the Hydra tutorial were completed, including CI workflows to keep it up-to-date. The team engaged in discussions with researchers about incremental commits & decommits, and drafted an architectural decision record for a resource-based API. They also explored simpler solutions for the upcoming network resilience feature.
The Mithril team has released a new distribution 2335.0 which brings enhancements to the client: support for simultaneous downloading and unpacking of the snapshot archives, support for one line command restoration of the latest snapshot, and availability of machine readable progress information.
They have also worked on snapshots enhancements: implementation of the zstandard compression to produce smaller archives, and providing the version of the Cardano node used to create the archive in the snapshot artifacts. They have completed the second phase of the implementation of the stress test tool to benchamrk the aggregator. Additionally, they have kept working on refactoring and standardizing errors in the Mithril nodes.
Finally, they have worked on adding Cloudflare protection to the infrastructure, and they have fixed some bugs that occurred during restoration of a snapshot by a client.
Use 'zstandard' compression for snapshot archives #876Design & implement stress test tool for aggregator - phase 2 #1155Provide progress information with '--json' option in Client #1095Make client download and extract the archive simultaneously #1115Add aggregator Cardano node version in snapshot artifact #948Make Cardano node version part of the Mithril network configuration #947Post deployment 'mainnet' infrastructure #1091Errors refactoring #798Add Cloudflare protection of infrastructure #986Failed to restore recent snapshot with strange error #1160Update 'ed25519-dalek' to '2.0.0' #1188Add target networks blocks in release notes #1151Fix end to end 'wait_for_the_expected_time' test #1191Fix docs 'git checkout' command #1174
master, supporting safe log truncation.master along with a curated configuration for 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.
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.
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.
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.