Ethereum’s evolution has always balanced decentralization, security and scalability. As rollups emerge as the dominant layer-2 scaling solution, the next critical step on the roadmap is improving how Ethereum handles data availability for those rollups. Proto-danksharding – widely known by its EIP number (EIP‑4844) – is a targeted protocol upgrade designed as a pragmatic, near-term bridge between today’s calldata model and the full sharded design envisioned by danksharding.At a high level, proto-danksharding introduces a new, cheaper data-carrying primitive (commonly called “blobs”) and an efficient commitment scheme that lets blocks reference large amounts of off-chain data without burdening full nodes with long-term storage of that data. The result is a notable reduction in layer-2 data costs and improved throughput for rollups, while preserving the security assumptions of the Ethereum main chain. Importantly, proto-danksharding stops short of full sharding: it implements the essential data-availability and pricing improvements first, enabling immediate scaling gains and laying the groundwork for a future multi-shard architecture.
This article will explain why proto-danksharding matters, how its core mechanisms function, what benefits and trade-offs to expect, and how it fits into the broader path toward danksharding. Whether you’re a developer building rollups, a validator/operator, or an informed user tracking Ethereum’s scaling roadmap, understanding this “prelude” is key to anticipating the network’s next phase of growth.
Proto Danksharding Objectives, Timeline and Transition Path to Danksharding
Proto-danksharding is being pursued with a concise set of objectives that balance immediate utility and long-term architectural evolution. At its core the effort seeks to dramatically lower data-availability costs for rollups by introducing cheap, large-capacity blob storage alongside existing calldata, while preserving Ethereum’s security model. Secondary goals include enabling real-world experimentation with blob-bearing transactions, incurring minimal consensus-layer disruption, and delivering measurable throughput gains for layer-2 systems prior to a full danksharding rollout.These aims are deliberately pragmatic: optimize for adoption, safety, and clear upgrade paths rather than radical simultaneous changes.
The roadmap is intentionally phased to reduce risk and allow iteration. Initial stages focus on specification, client implementation and local testnet validation. Subsequent steps advance through coordinated public testnets and shadow forks, then onto a mainnet activation window for the proto-feature set. After activation ther is a period of observation and parameter tuning before declaring readiness to progress toward the broader danksharding design. Each stage is timeboxed and gated by concrete performance and safety criteria so that the move from prototype to production is data-driven rather than speculative.
Transitioning from proto-danksharding to full danksharding follows a layered,technical path that emphasizes compatibility and incremental complexity reduction. Typical steps include:
- Specification deployment – finalize and accept proto EIPs producing blob-carrying transactions (e.g., EIP-4844).
- Client and validator updates - consensus and execution clients adopt blob handling and new gossipping/propagation rules.
- rollup integration - L2 systems add blob submission and adapt data-availability strategies.
- Operational tuning - adjust blob limits,gas pricing,and network heuristics based on testnet/mainnet data.
- Iterative upgrades – leverage learnings to introduce additional sharding primitives moving toward full danksharding.
Accomplished adoption relies as much on governance and coordination as on code. Core developers, client teams, rollup builders, validators and node operators must maintain tight dialog channels to manage activation windows, rollback plans and mitigations for unexpected edge cases. Community-led testnets, bug-bounty rounds and phased feature flags are essential to surface real-world issues early. Equally crucial is clear metrics reporting and the freedom to delay or adjust parameters if monitoring indicates elevated risk – a conservative, observable approach minimizes systemic disruption.
Practical success can be assessed with concrete KPIs that inform whether the network is ready for deeper sharding primitives. The table below summarizes representative targets used to decide readiness for the next phase:
| Metric | Proto Target | Dankshard Goal |
|---|---|---|
| Average blob cost (gas equiv.) | ≤ 10% of calldata cost | ≤ 1% of calldata cost |
| Rollup throughput uplift | 2-5× | 10×+ |
| Operational stability (incidents/month) | ≤ 2 minor | ≤ 1 minor |
Meeting these thresholds-combined with qualitative feedback from ecosystem participants-signals that the network can responsibly advance from proto-danksharding experimentation to the full danksharding architecture.
Core Protocol Architecture and Blob Data Flow with Practical Implementation Insights
At the core of the design lies a modular stack that cleanly separates consensus, blob availability, and execution. Key components include the sequencer (collects and orders transactions into blobs), the proposer/aggregator (packages blobs into blocks), and the availability layer (stores and serves blob data off-chain while anchoring proofs on-chain). This separation reduces L1 pressure by moving bulk payloads into a specialized flow, while the L1 remains the final arbiter of commitments and fraud-resistant data availability.
Blob lifecycle follows a deterministic path from creation to finality: generation, commitment, retrieval, and verification. Practical implementations must address each stage with clear interfaces and robust error handling. Typical engineering touchpoints include:
- Generation: client-side packing and compression before submission.
- Commitment: on-chain attestations of blob roots and metadata.
- Retrieval: peer-to-peer or CDN-assisted delivery for execution clients.
- Verification: proofs and signature checks prior to re-execution.
When building production systems, small implementation choices compound into large operational differences. Expose a minimal, well-documented API for blob access (GET by root, HEAD for metadata), implement layered caching for hot blobs, and enforce streaming validation so execution can begin before full download completes. The following compact table summarizes recommended defaults for a reference node implementation:
| Component | Recommended Default |
|---|---|
| Blob cache | LRU, 10-30 GB |
| Chunk size | 64-256 KB |
| Validation mode | Stream + checkpoint |
Performance engineering targets predictable latency and throughput while preserving security invariants. Focus on parallel verification, batching of cryptographic proofs, and asynchronous persistence to avoid blocking the critical path. Monitor for hotspots: network stalls during blob retrieval, memory spikes during decompression, and CPU contention in proof verification. Operational runbooks should include strategies for backpressure, retrial of missing blob segments, and graceful degradation to on-chain fallback when availability is uncertain.
Fee Market Mechanics, Blob Pricing Models and Economic Recommendations for Validators
Layered fee dynamics on the upgraded execution layer change how blocks are valued. Basefee remains the congestion signal for execution gas,while a parallel market for large binary payloads (blobs) introduces a new dimension: block builders now optimize across two scarce goods. validators must internalize that including a blob can increase short-term revenue but also affects the effective price per gas unit for ordinary transactions, shifting block composition trade-offs. Monitoring both mempool demand for calldata and blob demand is now essential to understand true block-level profitability.
The industry is converging on a few practical blob-pricing models, each with distinct economic incentives. Key approaches include:
- Flat-per-blob fee – simple, predictable; favors large blob producers but can underprice scarce capacity during demand spikes.
- Dynamic fee linked to basefee – blob cost scales with network congestion; aligns incentives but is more complex to implement.
- Tiered-size pricing - encourages efficient packing by charging based on blob size buckets; can reduce fragmentation.
Each model trades off simplicity, market efficiency, and susceptibility to rent extraction; validators should be prepared to adapt node and builder settings to whichever model is adopted on thier client or marketplace.
| Blob size | Example Fee | Effective Gas-Equivalent |
|---|---|---|
| 1 MiB | 0.01 ETH | ~100,000 gas/ETH |
| 4 MiB | 0.035 ETH | ~110,000 gas/ETH |
| 10 MiB | 0.08 ETH | ~95,000 gas/ETH |
For validators seeking stable revenue and low variance, adopt conservative inclusion rules: prioritize high basefee + tip bundles and accept blobs when the marginal blob fee exceeds the possibility cost of evicting execution gas revenue.Operational best practices include maintaining a configurable minimum blob fee threshold, tracking builder behaviour for MEV-related signaling, and using fee-estimation plugins that factor blob markets into profitability calculations. Do not automatically accept the highest nominal fee without modeling its impact on block acceptance probability and reorg risk.
coordination and transparency will reduce systemic risk. Validators should share anonymized metrics (average blob fill, acceptance thresholds) with peers, subscribe to aggregator feeds for blob-demand forecasts, and keep client software up to date to react to price-model changes. by combining active monitoring, adaptive fee policies, and modestly conservative acceptance rules, validators can extract new revenue streams from large payloads while preserving network health and minimizing adverse selection.
Developer Best Practices for Layer 2 Integration and Smart Contract Design
Adopt a modular mindset when architecting on-chain logic and off-chain glue. Break functionality into focused contracts and libraries so upgrades or rollups can target small, auditable units instead of monolithic deployments. Favor explicit interfaces and event-driven designs to surface important state transitions to Layer 2 indexers and relayers.Use battle-tested frameworks (such as, OpenZeppelin contracts) and prefer composition over inheritance where possible-this reduces surface area for bugs and simplifies gas profiling across execution environments.
Optimize for data-efficiency first: Proto-danksharding introduces new primitives that change the calculus for calldata vs storage. pack structs, prefer calldata-onyl parameters for read-heavy flows, and batch user actions into single transactions when safe. Use the following checklist during progress:
- Calldata-first: push ephemeral payloads through calldata/blobs rather than persistent storage.
- Batching: aggregate receipts and state updates to amortize per-tx overhead.
- Blob-awareness: estimate blob usage and choose serialization formats that minimize byte size.
- Lazy writes: defer storage writes until necessary and avoid redundant writes in hot paths.
Security patterns should be deliberate and well-documented. Follow Checks-Effects-Interactions for external calls, use role-based access control for privileged operations, and prefer short-lived privileges where possible. For upgradeability,make the trade-offs explicit: proxies enable fixes but require careful storage layout management. The table below summarizes common patterns and when to use them.
| Pattern | When to Use | Trade-off |
|---|---|---|
| Immutable | Core token logic | Max safety, no fixes |
| proxy Upgrade | Evolving protocols | complex storage, upgrade risk |
| Factory + Modules | Composable dApps | Better isolation, more endpoints |
Testing and observability must span both L1 and targeted Layer 2s. Create deterministic unit suites, replicable integration tests against L2 testnets, and fuzz or property-test critical functions. Instrument emitted events and include semantic logs for off-chain indexers. Adopt toolchains that understand the new data primitives-examples include Hardhat/Foundry for local testing, Tenderly or Forta for monitoring, and replay-capable traces for incident response. Prioritize continuous integration that simulates blob-carrying transactions and cross-rollup message flows.
Deployment and UX considerations finalize the developer workflow: design fallbacks when L2 data availability or relayer services degrade,and make fee estimation transparent for end users (show blob usage and cost breakdown). Maintain clear bridge contracts with robust dispute windows and event hooks for reconciliations. Before launch,verify these integration steps:
- Fee simulation: model worst-case blob pricing and gas spikes.
- Bridge drills: rehearse token and state migrations with testnet users.
- Graceful degradation: implement on-chain shutdown modes and off-chain notification channels.
- Documentation: publish developer guides for relayers, wallets, and indexers.
Security Analysis, Threat Models and Concrete Mitigation Strategies
Proto-danksharding expands attack surface in predictable ways: it introduces large-volume blob data, new availability dependencies, and additional vectors for proposer and sequencer manipulation. High-level threat actors include network-level adversaries aiming to degrade blob propagation, economically motivated actors trying to censor or reorder blob-carrying transactions for MEV, and subtle protocol-level attackers attempting to craft malformed commitments. Key attack vectors include blob withholding, commitment manipulation, sequencer censorship, and denial-of-service via high blob throughput.
- Blob withholding / partial availability
- Invalid or malformed KZG commitments
- Proposer/sequencer censorship or cartel behaviour
- Network-level congestion and targeted DDoS
Data availability is the single most critical axis for security: if blob data is withheld or lost, rollups and light clients cannot safely finalize state transitions. Proto-danksharding relies on KZG commitments and new Transaction types that carry blobs off-chain; this changes the assumptions about what data is always retrievable from L1. Practical mitigations here are layered: aggressive availability sampling by full nodes and light clients, redundancy in blob propagation paths, and incentivized relaying by economically aligning sequencers and relayers with data-availability outcomes.
Sequencer and proposer threats are predominantly economic and governance problems. Censorship-resistant designs should consider proposer-builder separation (PBS), transparent block production policies, and fallback inclusion rules that minimize time-to-inclusion for blob-carrying txs. At the same time, MEV extraction mechanisms must be audited to ensure they do not encourage collusion to withhold or reorder blob data. Operational countermeasures include strict monitoring of builder pools, public slashing or reputational penalties for censorship, and time-bound inclusion guarantees for high-priority rollup batches.
Protocol-level defenses combine cryptography, incentives, and on-chain checks. The table below summarizes typical threats and concise mitigations – a practical cheat-sheet operators and designers can reference when making decisions:
| Threat | Primary Mitigation |
|---|---|
| Blob withholding | Sampling + redundant relays |
| Commitment forgery | KZG binding + verifier checks |
| Sequencer censorship | PBS + inclusion timeouts |
| Network DDoS | Rate limits + geo-redundancy |
Defense-in-depth is required at the operational layer: node operators should run diverse connectivity points and verify blob availability locally, relayers should implement prioritized queueing for rollup batches, and rollups must adopt pragmatic fallbacks (e.g., fraud/availability challenge windows) to avoid liveness failures. For teams preparing the transition to full danksharding, conducting adversary exercises, running scaled availability simulations, and baking monitoring alerts into the validator/relayer stack are essential. By combining cryptographic guarantees with robust economic design and operational hygiene, the ecosystem can mitigate the majority of realistic threats while preserving the scalability gains proto-danksharding promises.
Testing Frameworks, staging Recommendations and Validator Readiness Checklist
Adopt a layered test strategy that exercises both the execution and consensus planes. Start with unit and integration tests for client code (use frameworks like Foundry/Anvil or Hardhat for EVM-level behavior, and native test harnesses for beacon clients). Complement those with fuzzing and property-based testing (Hypothesis/QuickCheck style) to uncover edge cases in RPCs and blob-handling logic. For end-to-end validation, run local multi-client clusters using Docker Compose or kubernetes to simulate proposer/validator interactions and blob propagation before moving to remote environments.
Stage deployments progressively to reduce risk: local development clusters → CI pipelines with deterministic snapshots → isolated public testnets → shadow forks of mainnet for realistic load → limited canary on mainnet. Each stage should include automated regression suites, telemetry hooks, and a fast rollback path. Recommended practices:
- Instrument every build with metrics and tracing.
- Use canary groups of validators for behavioral validation.
- Pin deterministic snapshots for CI reproducibility.
Maintain a concise readiness checklist that every validator operator and client maintainer must complete before enabling proto-dank features.The following table summarizes critical items and suggested actions:
| Check | Recommended action |
|---|---|
| Key management | verify offline cold key backups and test restores |
| Client diversity | Run at least two self-reliant client implementations |
| Slashing protection | Enable and test cross-client slashing DB export/import |
| monitoring | Set alerts for propagation latency, failed proposals, and blob inclusion |
Define strict acceptance criteria for automated test runs and manual validation cycles. Target blob inclusion success > 99% under nominal conditions, keep median slot propagation latency < 500 ms, and ensure chain reorgs remain bounded to ≤2 slots in resilience tests. Include stress tests that push gas-per-slot and data-gas limits, as well as long-duration soak tests to reveal memory leaks and resource exhaustion. Log and tag every failing run with reproducible inputs for rapid debugging.
Operational readiness requires concrete runbooks and a practiced rollback plan. Prepare short runbooks for:
- Hotfix deploy – steps to patch and restart a validator safely.
- Rollback plan – how to revert canary to previous binaries and revoke risky flags.
- Incident escalation – contacts, postmortem cadence, and communication templates.
Ensure all teams periodically rehearse these steps in blue/green or chaos drills so recovery becomes predictable and auditable.
Operational Monitoring, Key Metrics to Track and Governance and Upgrade Considerations
Operationalizing proto-danksharding requires a comprehensive telemetry surface that spans nodes, relayers, sequencers and L1 bridges. Instrumentation should capture both on-chain and off-chain signals: RPC latency, disk and network I/O for blob storage, mempool depth and propagation time, and L1 calldata footprint.Use mature observability stacks - prometheus for metrics, Grafana for dashboards, structured logs (JSON) and a tracing system (Jaeger/Tempo) to correlate end-to-end flows. Capturing high-cardinality labels early (e.g., relayer ID, blob size bucket, chain-id) makes post-incident analytics far more effective than ad-hoc instrumentation added after problems appear.
Focus on a concise set of high-value metrics that correlate to user experience and protocol health. Track:
- Tx throughput (tx/s) – overall application capacity.
- Blob throughput (blobs/block & blobs/s) - how much data the rollup is pushing toward danksharding primitives.
- Calldata footprint (bytes/L1-block) – L1 resource consumption and cost driver.
- Inclusion delay (mempool → block) – latency experienced by users.
- Sequencer/Relayer uptime & latency – operational availability and responsiveness.
- Gas per block & average gas price - economic pressure indicators.
- Reorg rate & orphaned blobs – consistency and safety signals.
These metrics should be collected at 10s-1m resolution for alerting and aggregated to 1h-24h for trend analysis and capacity planning.
Design actionable alerts and runbooks: excessive mempool growth should trigger a throttling playbook, repeated failed blob commitments should escalate to on-call, and sustained L1 gas spikes should trigger economic-mitigation steps (e.g., temporary fee repricing). Typical alerts to configure include:
- mempool depth > X transactions for Y minutes
- blob inclusion delay > Z seconds
- blob validation/availability failures > N per hour
- relayer RTT or error rate above threshold
- unexpected growth in L1 calldata consumption
Each alert must map to a short, tested runbook with roll-forward and roll-back options and a clear owner to reduce mean time to resolution (MTTR).
Upgrading toward full danksharding is as much a governance and coordination challenge as it is a technical one. Adopt a phased activation plan: RFC → testnet deployments → shadow mainnet runs → soft-fork activation window with clearly communicated block numbers and client support matrix. Governance mechanisms (on-chain signaling, multisig coordination, L2 sequencer/operator alignment) should be used to confirm readiness. Prepare compatibility shims, default-off feature flags, and economic parameter tuning windows so that if a critical metric drifts post-activation the community can rapidly vote or coordinate a mitigation. Crucially, maintain a documented rollback strategy – including state export/import plans and warm standby nodes – to reduce risk when making changes that affect data availability primitives.
Operational readiness can be summarized into a lightweight checklist and monitored dashboard. Below is a compact table you can adopt on an operations landing page to focus attention on the highest-impact items.
| Metric | Why it matters | Critical threshold |
|---|---|---|
| Blob inclusion delay | Latency from submission to on-chain inclusion | > 30s (investigate) |
| Calldata bytes / L1 block | Direct L1 cost and congestion signal | > 80% of block gas |
| Relayer error rate | Availability of off-chain transport | > 1% sustained |
| Reorgs / hour | Chain stability and safety | > 0.1/hr |
Keep dashboards simple, set clear SLOs, and run frequent upgrade drills – observing these metrics before, during and after any proto-danksharding rollout is the best defence against surprises.
Q&A
Q: What is proto-danksharding?
A: Proto-danksharding (commonly associated with EIP-4844) is a protocol upgrade for Ethereum that introduces a new transaction type able to carry large, separate pieces of data called “blobs.” The change is designed to dramatically reduce the on-chain cost of posting rollup data by making that data cheaper and more easily prunable, and it serves as an intermediate step toward full danksharding.
Q: How does proto-danksharding differ from the existing calldata model?
A: Today, rollups publish transaction data using calldata, which is stored by nodes indefinitely and priced at a relatively high gas cost. Proto-danksharding adds blobs – large,EVM-inaccessible data payloads attached to blocks – that are cheaper to include than calldata and can be pruned by nodes after they are no longer needed.The EVM continues to use calldata as before; blobs exist as a separate data layer optimized for rollup usage.
Q: What are blobs and how are they handled on-chain?
A: blobs are large binary data attachments included with certain transactions. Each blob is represented on-chain by a compact KZG commitment (a cryptographic commitment) and a short commitment entry is stored in the block. The full blob payloads are carried by block producers and node implementations but are not addressable by smart contracts. Nodes may discard the full blob payloads after a retention period while keeping the commitments on-chain.
Q: Why are KZG commitments used?
A: KZG polynomial commitments let the chain record a short commitment that cryptographically binds to the larger blob payload. This compact on-chain depiction is essential for future features like data availability sampling and full danksharding, where nodes need to verify that data is available without storing all of it permanently.
Q: how does proto-danksharding benefit rollups (Layer 2s)?
A: By offering a much cheaper, higher-capacity data path, proto-danksharding reduces the cost for rollups to publish their transaction batches to L1.The lower per-byte pricing for blobs should materially reduce L2 data costs and improve effective scalability for rollups without changing rollup execution or security assumptions.
Q: Does proto-danksharding change consensus or execution security?
A: Proto-danksharding introduces changes to how blocks carry and account for blob data but does not alter Ethereum’s execution model for smart contracts. Consensus validators still verify block signatures and commitments. The security model is preserved: the on-chain commitments ensure integrity of blob data, and proto-danksharding is designed to be compatible with existing consensus rules while enabling future data-availability mechanisms.
Q: How does proto-danksharding relate to full danksharding?
A: Proto-danksharding is a pragmatic precursor to full danksharding. It implements the key primitives (blobs and KZG commitments) needed for a data-efficient L1 and prepares the protocol for the more ambitious full danksharding design, which would add many data shards, native data-availability sampling, and higher aggregate data throughput. Proto-danksharding lowers barriers and provides immediate benefits while the full design is finalized and implemented.
Q: Will smart contracts be able to read blob contents?
A: No. Blob contents are intentionally not accessible from the EVM. Blobs are designed for rollups and off-chain clients to publish and retrieve batch data efficiently while preventing direct contract-level dependencies on large blob payloads.
Q: How will proto-danksharding affect transaction fees and user experience?
A: Users of rollups should see lower L2 transaction costs because rollup operators will be able to compress and publish data more cheaply.L1 transaction fees for calldata-heavy use cases should decline in relative terms. for average end users interacting with smart contracts directly on L1, the experience is unlikely to change considerably; the most noticeable effect will be lower costs and higher throughput for Layer 2 rollups.
Q: What must infrastructure providers do to support proto-danksharding?
A: clients, node operators, rollup sequencers, aggregator services, block explorers, and wallets may need updates. Client implementations must support the new blob-transaction format and KZG commitment logic. Rollups and sequencers should adapt to publish data in blob form and to handle any new fee accounting. Indexers and explorers must extend their tooling to index blob commitments and any associated metadata.
Q: are there any risks or trade-offs?
A: Key trade-offs include added protocol complexity, the need for careful client implementation and auditing (KZG and blob handling), and temporary storage pressures during the transition while tooling matures. There are also economic shifts to consider: lower L2 data costs change fee dynamics and may affect MEV extraction patterns and sequencer economics.As with any major upgrade,implementation bugs or misconfigurations pose operational risk until the ecosystem stabilizes.
Q: How does proto-danksharding affect node storage and pruning?
A: Proto-danksharding is explicitly designed to allow nodes to prune full blob payloads after a retention window, keeping only compact commitments on-chain. This reduces long-term storage requirements compared with indefinitely storing all posted rollup data as calldata. Node operators will need to run updated client versions that implement the new retention/pruning behavior.
Q: Is proto-danksharding already live on Ethereum mainnet?
A: Deployment status can change-proto-danksharding (EIP-4844) has been implemented in client codebases and tested on testnets, but mainnet activation depends on the Ethereum governance and client release schedule. For the most current deployment status, consult official client release notes and Ethereum Foundation communications.Q: What comes next after proto-danksharding?
A: After proto-danksharding, the next step is full danksharding: a design that expands to many data shards, enables native data-availability sampling, and scales aggregate L1 data capacity dramatically. Proto-danksharding lays the cryptographic and protocol groundwork (blobs, KZG commitments) that full danksharding will build upon.
Q: Where can readers learn more or follow updates?
A: Readers should consult the EIP text for EIP-4844, client release notes, Ethereum foundation blog posts, and developer community channels for specification details, implementation progress, and best-practice guidance. These are the authoritative sources for technical details and deployment timelines.
If you’d like, I can convert this Q&A into an FAQ section formatted for publication, or expand any answer with diagrams, examples, or brief implementation notes for node operators and rollup builders.
To Wrap It Up
proto-danksharding is a purposeful, incremental upgrade: it introduces a new, cost-effective way to carry large ephemeral blobs of data that rollups can use, without changing Ethereum’s core state model.By reducing calldata costs and providing a standardized path for rollup data availability,it materially improves rollup economics today while laying the groundwork for the broader architectural changes that full danksharding will bring.
That said, proto-danksharding is a prelude, not the destination. Its success depends on coordinated client implementations, rollup integrations, tooling updates, and ongoing research into the full danksharding design and data-availability mechanisms. Developers, validators, and protocol watchers should track EIPs, testnet deployments, and client release notes to understand migration steps and to validate real-world performance gains.
For stakeholders across the ecosystem, proto-danksharding represents a pragmatic balancing of immediate scaling needs and long-term design goals. It reduces costs and complexity for rollups now,while buying the time needed to develop and safely deploy the more ambitious danksharding vision. Stay informed, test early where possible, and prepare tooling and infrastructure to take full advantage of the opportunities ahead.
