Artificial intelligence programs are increasingly operating directly on blockchains, requiring the underlying platforms to be both highly scalable and secure for the long term. NEAR’s unique architecture, with its sharded design and account system, positions it well as developers rebuild infrastructure to support self-running applications and applications that handle large amounts of data.
This article explains why dynamic resharding and quantum-safe signing are so important for NEAR’s development in the field of artificial intelligence. It will cover how these technologies function, how they impact developers, potential risks to consider, and practical steps you can take to get ready.
Quick Answer
NEAR Protocol is improving how it handles data by automatically dividing and combining it to meet changing needs, which helps keep transaction costs low and speeds things up, especially for unpredictable AI tasks. It’s also preparing for the future by using new types of encryption that will stay secure even if powerful quantum computers are developed. These improvements create a system that can easily grow with demand and adapt to new security challenges, allowing it to scale up when activity increases and update encryption methods as technology advances.
- Elastic capacity: shards adapt to load instead of forcing apps to migrate manually.
- Better UX: steadier fees and lower congestion during AI-driven bursts.
- Crypto agility: account-level key rotation enables gradual PQC adoption.
- Risk-aware: resharding adds cross-shard design complexity; PQC adds overhead.
How does NEAR’s dynamic resharding actually work?
NEAR’s core technology, Nightshade, divides the network’s information across multiple shards that process data in parallel. Validators create small pieces of data called “chunks” for each shard and then combine them into blocks. Dynamic resharding allows the network to automatically split busy shards into more shards or combine lightly used ones, all based on how the network is performing. This helps maintain optimal performance without requiring app developers to manually intervene.
As an analyst, I’ve seen how elasticity really helps manage AI application performance. When demand surges – like with lots of inference requests or bidding between AI agents – we can automatically split the underlying data storage to spread the load. Then, when things calm down, we merge that storage back together to cut costs. This approach keeps fees predictable and ensures transactions are processed quickly, even during peak times.
NEAR Protocol has been gradually improving its sharding technology through phases like Simple Nightshade and by adding more shards over time. The ability for the network to automatically split and merge shards has been planned for a while and has undergone testing and initial implementation. Because the specifics of how NEAR works are always changing, developers should always check the official NEAR documentation for the most up-to-date information before building anything that depends on particular features.
Developers should keep in mind that they shouldn’t depend on fixed shard IDs, their contracts need to be designed to work with calls across different shards, and they should be prepared for the possibility that the network might move their contract’s data around to improve performance.
Why do AI agents and data-heavy apps benefit from elastic sharding?
AI systems can sometimes act in unexpected ways, experiencing sudden spikes in activity due to things like software updates, popular new instructions, or a lot of requests happening at once. Elastic sharding is a good solution for this because it automatically increases resources when demand is high and then scales back down when things calm down, helping to avoid unnecessary costs from over-preparing for peak usage.
Several emerging uses of AI on blockchains – like paying for AI services with each use, verifying data as it streams in, and auctioning off AI access – cause brief surges of activity focused on specific smart contracts. Automatically adjusting how the blockchain is divided (dynamic resharding) can prevent these concentrated bursts from slowing down the entire network, ensuring fast transaction confirmations for everyone.
Essentially, elasticity makes things more predictable. When transaction fees and available network space are more consistent, it becomes easier to set prices for AI tasks or guarantee reliable performance for automated transactions. Consistent and stable fees also make it simpler for teams to manage budgets for agents that need pre-funded accounts.
- Checklist for AI builders on NEAR
- Avoid assuming a fixed shard layout; expect state to move.
- Design idempotent cross-contract calls to tolerate retries.
- Instrument end-to-end latency and cross-shard hop counts.
- Use queues or batching for bursts; backoff on congestion signals.
- Pre-fund agent wallets with margins for transient fee variance.
What is “quantum-safe signing,” and why care now?
Quantum-safe signing, also known as post-quantum signing, uses digital signatures built to withstand attacks from future quantum computers. The digital signatures we commonly use today, such as ed25519 and secp256k1, could be cracked by powerful quantum computers using an algorithm called Shor’s algorithm. Although we don’t know exactly when this will happen, there’s a real risk that attackers are already collecting encrypted data now, planning to decode it once they have access to quantum computing power.
Organizations that set technical standards are choosing post-quantum cryptography (PQC) algorithms for widespread use. The U.S. National Institute of Standards and Technology (NIST) has identified promising candidates like CRYSTALS-Dilithium, Falcon, and SPHINCS+. These options differ in how much digital space their signatures take up, how quickly they can be verified, and how difficult they are to implement. Blockchains are expected to initially use a combination of traditional and post-quantum signatures, allowing both methods to confirm transactions and providing a gradual transition to the new technology.
Web3 projects need to be flexible with their cryptocurrency setups right away. Managing funds over the long term, creating secure identities, and connecting different blockchains all require it. Switching systems takes time – wallets, software tools, physical devices, and smart contracts all need to work together and have consistent ways to recover if something goes wrong.
Switching to post-quantum cryptography (PQC) will take time. It’s best to begin by building ‘crypto agility’ – the ability to easily change or add encryption keys – before choosing a specific PQC method. Always check the latest recommendations in official standards and the NEAR documentation.
Can NEAR’s account model simplify PQC migration?
NEAR Protocol handles accounts differently than many other blockchains. Accounts are designed to be easy to read and understand, and each one can have several access keys, each with its own specific permissions. Some keys have full control, allowing any transaction, while others are limited to authorizing particular actions on smart contracts and can control how much the account spends. This detailed key system makes it safer to try out new security technologies and gradually introduce updates.
When preparing for post-quantum cryptography (PQC), teams can start incorporating new access keys that utilize either a PQC or a combination of traditional and PQC signature methods. This can be done as soon as the system supports it, or through smart contract-based wallets. During the switch to PQC, actions could require signatures from both current and post-quantum algorithms (a multi-algorithm, multi-signature approach), or require a certain number of keys, including at least one PQC key. This approach minimizes the risk of failure if a single algorithm is compromised.
NEAR Protocol’s features, like multisignature accounts and regularly changing keys, allow large organizations managing crypto to test and implement better security practices. They can schedule key rotations, try out changes on test accounts, and easily revert if problems occur. Although full adoption of post-quantum cryptography (PQC) depends on the broader crypto community, NEAR’s adaptable account system offers a practical way to start using it without affecting regular users.
Always refer to the official NEAR documentation for the most up-to-date information on features and planned changes. For any custom wallets or multi-signature setups you build, it’s also a good idea to have them professionally audited.
How does NEAR compare for AI-era scaling?
Different blockchain platforms are approaching the challenges of AI applications in different ways. Some are focusing on breaking data into smaller, more manageable pieces (elastic sharding), while others are building systems that can handle a large volume of transactions all at once, or relying heavily on data compression techniques. Here’s a general overview comparing how easy these platforms are to use for building AI-powered applications and how adaptable they are to new technologies. Keep in mind that these platforms are constantly changing, so it’s best to check each platform’s official documentation for the most up-to-date information.
Here’s a breakdown of how different blockchain platforms handle scaling, flexibility, accounts, and preparation for post-quantum cryptography (PQC):
NEAR: NEAR uses a system called ‘Sharding’ on its main layer (L1) called Nightshade. This allows it to dynamically split and merge parts of the blockchain to adjust to demand. It uses named accounts with multiple access keys and built-in support for managing multiple signatures. NEAR is well-positioned for PQC through key rotation and flexible policies, and is working towards native PQC implementation as the broader ecosystem adopts it.
Ethereum (+ rollups): Ethereum relies on its main layer (L1) combined with ‘rollups’ (L2) which are separate layers that handle transactions. This modular approach allows scaling by adding more L2s. Ethereum uses traditional accounts and is adopting more advanced ‘contract wallets’ (ERC-4337). PQC implementation is expected to happen first with ‘smart wallets’, guided by NIST standards and community input.
Solana: Solana is designed as a single, high-performance blockchain. It scales by adding more hardware and optimizing its internal scheduler. Solana uses keypairs for accounts and program-derived addresses. Research into PQC is ongoing, and switching to PQC will require updates to wallets and the blockchain’s runtime.
Other Sharded L1s: Various other blockchains use sharding, dividing the blockchain into smaller parts, either for data storage or transaction processing. Some of these support dynamic resharding. Account abstraction varies across these platforms. PQC readiness is mixed, with many exploring hybrid signature schemes.
AI developers have a straightforward choice when building agents: NEAR Protocol offers flexibility to handle sudden increases in activity and a user account system that simplifies updates. While rollup-based systems provide customization and options, they can sometimes split resources across different networks. Traditional blockchains are easier to integrate with, but require more powerful hardware to manage peak demand.
What are the risks and trade-offs to weigh?
Implementing improvements for scalability and security always comes with challenges. Techniques like automatically adjusting data distribution and using post-quantum cryptography aren’t simple solutions, and system designers need to consider these complexities from the start. This is especially crucial for AI systems, where even brief interruptions or unexpected costs can damage customer trust.
Switching to a sharded system introduces the need for coordination between different parts of the system. If contracts rely on each other to complete tasks, this can add delays and unpredictable response times if those contracts end up on separate shards. To address this, developers will need to use tools and techniques like sending messages without waiting for an immediate response, automatically retrying failed operations, and setting time limits for tasks. Also, keeping track of how data is divided across shards becomes more important, so you’ll want systems in place to alert you when those divisions change.
Post-quantum cryptography also impacts how well things perform and how easy they are to use. Many new digital signatures are larger than current ones, which could increase transaction costs, storage needs, and data usage. Checking these signatures can also take more computing power. This means hardware wallets and secure chips will require updates, and the way we back up our data needs to be revised. Combining traditional and post-quantum methods can reduce risk, but it also makes the systems more complicated.
Both key rotation and resharding need careful planning and established rules. For key rotation, you’ll need clear guidelines on how often keys change, what to do if a key system is retired, and how to inform users about updates. When it comes to resharding, it’s vital to share configuration details, monitoring tools, and test environments so teams can practice the migration process without risking problems.
What should builders do next?
Being prepared is more valuable than trying to guess what will happen. You don’t have to wait for the perfect technology or system setup to begin minimizing potential problems. Think of it as a project with clear, achievable steps that you can manage.
Begin by building flexibility into your encryption systems. Keep a complete list of all your encryption keys, set regular schedules for changing them, and put in place multi-signature or threshold policies. These can be expanded later to include more advanced, hybrid encryption methods. Also, create and maintain an approved list of encryption algorithms for each environment, and ensure this list can be updated through a secure and reviewed process.
Next, prepare your system for resharding. Design it to avoid relying on specific shard configurations, use asynchronous processing, and thoroughly test it with simulated traffic patterns that resemble AI workloads. Monitor response times at the 50th, 95th, and 99th percentiles as data crosses between shards, and analyze how sensitive your system is to gas and transaction fee fluctuations.
- Action plan for the next quarter
- Read NEAR’s sharding and account docs and verify current resharding status: NEAR Documentation.
- Implement account-level key rotation on staging; add an auxiliary key and exercise recovery paths.
- Pilot a contract wallet that can accept multiple signature schemes (classical today; PQ-ready interface).
- Add cross-shard observability: shard layout alerts, hop counters, and fee/latency dashboards.
- Run chaos drills: simulate shard splits/merges and key compromise; document operator playbooks.
- Track PQC standards at NIST: NIST PQC.
Common Mistakes
- Hardcoding shard assumptions: Designing contracts that rely on static shard IDs or synchronous calls to a specific shard. Fix by using asynchronous patterns and avoiding storage layouts that assume immobility.
- Skipping key rotation drills: Waiting for a PQC “final answer” before practicing rotations. Fix by instituting regular rotations and canary accounts so you can swap algorithms later without user pain.
- Underestimating PQC overhead: Assuming signature sizes and verification costs are negligible. Fix by benchmarking larger payloads, adjusting fee buffers, and planning storage impacts.
- Neglecting wallet UX: Rolling out new key types without clear recovery flows. Fix by updating backup formats, educating users, and ensuring hardware/software wallet support.
- One-shot migrations: Flipping all keys to a new scheme at once. Fix by adopting hybrid signatures and phased rollouts with rollback plans.
- Thin observability: Lacking metrics on cross-shard latency, failure rates, and layout changes. Fix by instrumenting hop counts, queue depths, and alerting on shard reconfigurations.
For more editorial insights and hands-on explainers as this space evolves, visit Crypto Daily.
Frequently Asked Questions
Does dynamic resharding break composability across contracts?
While systems can still be built by combining different parts, this process is becoming more reliant on things happening out of order. When different parts of a system need to communicate across separate databases, it can cause delays and sometimes require retries. To handle this effectively, it’s best to use message queues, set time limits for operations, and design systems that can function even if data isn’t immediately consistent everywhere. Testing by simulating database separations can help identify potential weaknesses.
Will dynamic resharding lower my fees automatically?
This technology can balance network activity, preventing congestion that leads to higher costs. However, costs still fluctuate based on how much the network is used and its overall settings. Instead of relying on a guaranteed minimum cost, it’s better to plan for occasional spikes and build in some flexibility.
How soon do I need quantum-safe signatures?
While we don’t know exactly when quantum computers will pose a threat, organizations with valuable, long-term data and systems should prepare now by using flexible cryptography. This means setting up accounts that can handle multiple encryption methods, planning how to switch encryption keys, and supporting systems that combine current and future encryption standards. This will allow a smooth transition to quantum-resistant cryptography when it’s widely available.
Which PQC algorithms are most likely for blockchains?
NIST has chosen several promising post-quantum cryptography algorithms, including CRYSTALS-Dilithium, Falcon, and SPHINCS+. Each algorithm has different strengths and weaknesses regarding signature and key sizes, and how quickly signatures can be verified. Many blockchain projects are expected to begin by combining traditional digital signatures with these new post-quantum signatures, making the transition smoother and reducing the risks of adopting the technology too early.
Can I implement PQC on NEAR today?
Teams can get ready for post-quantum cryptography by using secure wallet setups, multiple signature requirements, and key rotation plans that are compatible with this new technology in both how they operate and how data is stored. Whether specific post-quantum encryption methods are directly supported depends on community standards and future updates to the system. Before building your own cryptographic solutions, it’s best to check the NEAR documentation and current community discussions.
How do I avoid vendor lock-in with PQC?
Prioritize using well-established, standard algorithms, and choose wallets that can be updated with transparent and verifiable management. Always record details about the method used for creating signatures. When updating or replacing algorithms, aim to do so without requiring users to change their addresses whenever possible.
What’s the best way to communicate these changes to users?
To make things smoother, share clear schedules for changes, plan rollouts in stages, and offer guides for fixing any issues. Let users test new wallets or keys in a safe environment first. For those managing funds, openly share rotation schedules and approval processes. Being open about these details will help avoid confusion when systems are updated or security is improved.
Read More
- APT PREDICTION. APT cryptocurrency
- USD RUB PREDICTION
- Gold Rate Forecast
- USD JPY PREDICTION
- SOL PREDICTION. SOL cryptocurrency
- USD CNY PREDICTION
- ZEC PREDICTION. ZEC cryptocurrency
- PEPE PREDICTION. PEPE cryptocurrency
- NEAR PREDICTION. NEAR cryptocurrency
- USD TRY PREDICTION
2026-05-23 14:34