On January 21, 2026, Vitalik Buterin proposed a new scheme for Ethereum's "native DVT" staking on the Ethereum Research forum, once again bringing the technical design of the staking layer to the forefront. This proposal attempts to lower the threshold for participating in staking directly at the protocol layer by allowing individual validators to register multiple independent keys; on the other hand, it aims to enhance the network's Nakamoto coefficient to combat the systemic risks posed by the concentration of staking power in a few large operators. The question is to what extent the existing business models and technical paths relied upon by current DVT clients, staking service providers, and node operators will be rewritten when "DVT capabilities" are reclaimed from the application layer to the protocol layer, which has become the core tension surrounding native DVT.
From Lido's Dominance to a Protocol Layer Counterattack
● The reality of staking centralization has long been evident: after the merge and Shanghai upgrade, the scale of Ethereum staking rapidly expanded, but Lido's staking share once exceeded 30%, becoming an unavoidable systemic node. This means that over one-third of the validation power is concentrated in the hands of the same protocol and its operating alliance, combined with the centralized node layouts of other large trading platforms and custodians, leading to community concerns that "once something goes wrong, it will be system-level." The staking landscape, originally under a decentralized narrative, is being reshaped by a few institutions.
● The threats posed by centralization are multifaceted: when staking power is overly concentrated, it theoretically becomes easier to form censorship alliances under regulatory pressure or policy games, filtering specific transactions and addresses; a lower Nakamoto coefficient means that the "number of participants" required to attack the network or initiate protocol layer governance manipulation decreases, implicitly lowering the cost of wrongdoing; at the same time, the discourse power in governance voting and technical route selection is more easily hijacked by large staking service providers and custodians, marginalizing small nodes and retail stakers in decision-making, which directly conflicts with Ethereum's long-advocated principle of "broad participation and multipolar checks and balances."
● For this reason, the community has begun to reflect on whether "relying solely on the application layer" is sufficient: existing DVT clients and multi-party operational practices have indeed enhanced the robustness of individual validators to some extent, but they struggle to fundamentally reverse the trend of power concentration—self-discipline among operators and off-protocol governance are easily influenced by commercial interests and regulatory games. Thus, writing part of the distributed validation capability "into the protocol itself," no longer fully relying on external coordination and voluntary constraints, has become a direction frequently mentioned in many technical discussions, laying the groundwork for this native DVT proposal.
What Native DVT Looks Like: Multi-Key and In-Protocol Splitting
● According to the currently disclosed information, the core of this native DVT concept is: an individual validator can register multiple independent keys at the protocol layer, which can be hosted and operated by different entities and nodes in different geographical locations. In simple terms, it breaks down the original model of "one validator = one key = one machine/set of nodes" into "one validator = a set of keys = multiple collaborative nodes," with the protocol responsible for recognizing and scheduling the signatures generated by this set of keys, thereby increasing redundancy and improving fault tolerance without changing the staking amount.
● Regarding performance impact, a prevailing view in the market is that: this design has limited impact on consensus performance, only adding a round of delay in the block production path, with the overall still within an acceptable range. However, this judgment currently seems more like a preliminary estimate based on the experience of engineers and researchers, belonging to information pending verification—the actual network latency, inter-regional node communication quality, and client implementation details may amplify or reduce this additional overhead, ultimately requiring more rigorous conclusions through testnets and prototype implementations.
● For security and penalty mechanisms, some discussions suggest that as long as a reasonable signature threshold is set on the "multi-key set," it can maintain the effectiveness of the existing slashing logic while enjoying higher fault tolerance— for example, only triggering severe penalties when a sufficient number of keys collude in wrongdoing or are offline for an extended period. However, parameters including specific thresholds and mathematical assumptions are currently still within the scope of verification and cannot be simply transplanted into the mainnet reality. Finding a balance between increasing resilience and preventing collusion remains an unsolved problem for this native DVT design.
Protocol Layer Innovation vs. Power Restructuring of Existing DVT Clients
● Existing DVT client solutions largely rely on external coordination layers: by using threshold signatures, consensus libraries, and governance structures of operators, a group of independent nodes is "bound into a virtual validator." The limitation of this architecture is that participants must trust the client team and operators in their decisions regarding parameter selection, upgrade paths, and fault handling, while also bearing the additional risks brought by external coordination failures. Once a certain operating alliance changes its strategy under economic or legal pressure, individual nodes often have little bargaining power.
● With the introduction of native DVT, the landscape of staking power is expected to be redrawn: if the protocol itself provides multi-key registration and validation capabilities, small nodes can form "key alliances" more lightly, without having to cede too much control to a single operating entity; staking service providers may shift from being "absolute centers" to "coordinators and brand service providers," while node operators gain more dominance, and retail stakers can avoid having their funds and permissions completely locked into a few platforms through more granular decentralized configurations. This shift from application layer governance to in-protocol mechanisms essentially rewrites the power contracts between different participants.
● However, the provision of DVT capabilities at the protocol layer inevitably impacts the business models of third-party DVT projects: when "multi-key, multi-node collaboration" becomes part of the underlying consensus, existing projects need to reprove their differentiated value to the market, such as more refined risk management, more user-friendly operational tools, or more flexible profit distribution mechanisms. At the same time, the ecological competition between old and new solutions will intensify—client teams, infrastructure providers, and large staking service providers may engage in covert battles over standard-setting, parameter selection, and even default integration paths, determining whether DVT technology in the coming years exists as "in-protocol general capabilities" or "external specialized services."
The Tug-of-War Between Lowering Barriers and Increasing Nakamoto Coefficient
● The intuitive benefit of multi-key registration lies in providing higher fault tolerance for small nodes and geographically dispersed stakers: the same validator can distribute keys to nodes operating in different regions and backgrounds, so that even in the event of local network failures or single-point hardware damage, it does not immediately trigger penalties or long-term offline status. This structure encourages more small-scale participants to dare to launch validation nodes, thereby diluting validation power across a broader area and population without changing the total staking amount, theoretically helping to raise the network's Nakamoto coefficient.
● However, multi-key and threshold settings are also a double-edged sword: if the allowed number of keys is too high and the threshold too low, it may weaken the cost of wrongdoing— a few participants can control validator behavior without significantly increasing the difficulty of collaboration, thereby undermining the security promise of "decentralization"; conversely, if the threshold is set too high, normal operation requires more keys to be online and collaborating, making it easier to trigger offline or instability if individual nodes fail, placing excessive operational pressure on honest participants. Finding a reasonable range between these two extremes will be a long-term game of tug-of-war between academic modeling, simulation testing, and practical operational feedback.
● In addition to the trade-offs between security and incentives, there are also unavoidable performance and complexity overheads: multi-key and multi-node collaboration will inevitably increase network message round trips and client implementation complexity, which means more potential attack surfaces and operational issues; coupled with the fact that there is currently no public conclusion on specific implementation paths, client integration methods, and the degree of coupling with existing consensus logic, rashly providing a timeline or rollout rhythm will only create expectation bubbles. How to progressively introduce native DVT without sacrificing network robustness remains an unresolved practical issue.
Regulatory Shadows and Geopolitical Computing: A Metaphor Beyond Russia
● On a larger scale, the geopolitical flow of computing power and staking nodes also provides a side note to the value of native DVT. A single source indicates that illegal mining in Russia causes approximately $250 million in losses to the local power grid and finances each year, accompanied by the process of legalizing mining starting at the end of 2024 (also pending verification), leading to a new round of games on how to redistribute computing power and related profits within a regulatory framework. Although these details await more supporting data, they at least reveal a reality: when policy attitudes waver, computing power and validation nodes will realign across national borders.
● In the rapidly changing global geopolitical and regulatory environment, the migration paths of staking nodes may become more frequent: certain jurisdictions tightening node operation, staking income taxation, and compliance obligations will force operators to relocate servers and corporate entities; while others attempt to attract nodes and capital through friendly regulations. This "geopolitical rebalancing" suggests that once a single region or camp holds too high a proportion of validation power, it becomes easier to become a source of systemic risk in macro conflicts or sanctions, while decentralized operation across multiple regions and entities is no longer a technical ideal but a practical need to avoid geopolitical black swans.
● In this context, native DVT provides a potential defensive tool for cross-regional and cross-entity decentralized validator risks: through protocol layer-supported multi-key and multi-node collaboration, a validator can consciously "disassemble" itself under different countries and compliant entities, thereby reducing the probability of being "completely cut off" by a single regulatory environment. However, this concept also needs to be approached with caution—different countries have inconsistent legal interpretations of cross-border key custody, data flow, and node control, and to what extent native DVT can genuinely mitigate geopolitical risks, rather than being constrained by new compliance requirements, remains to be verified over a longer period.
Ethereum's Next Step: Experiment or Paradigm Shift
● From a technical and institutional perspective, native DVT opens a new problem-solving space for Ethereum in lowering staking barriers and resisting centralization: multi-key registration and in-protocol collaboration are expected to allow more small-scale, cross-regional participants to safely assume validation responsibilities, thereby enhancing the Nakamoto coefficient and weakening the dominance of a single staking alliance. However, there are still many unresolved questions regarding performance loss, threshold parameters, security boundaries, and integration with existing client ecosystems; any attempt to directly package it as "the next definitive upgrade milestone" is a reckless simplification of complexity.
● More realistically, the currently available public information has limited coverage of key technical details, and some performance assessments and slashing compatibility claims are explicitly marked as pending verification; the true positions of core developers in internal discussions and the preferences of different client teams regarding implementation paths have not yet been systematically presented. In this unclear stage, a reasonable attitude towards native DVT may be to view it as an important but still experimental research direction, rather than a predetermined answer already written into the roadmap.
● In the coming period, the game between the community, client teams, and staking service providers regarding native DVT is likely to present multiple parallel lines: some routes will emphasize gradual experimentation, refining parameters and security models in testnets and small-scale practices; others may advocate leaving more innovations at the application layer, allowing the market to vote with its feet among various DVT solutions; and a compromise solution of "protocol providing basic capabilities + third parties adding governance and operational services on top" cannot be ruled out. Regardless of where it ultimately leads, it is certain that native DVT is not just an engineering optimization attempt, but a long-term variable cast between the structure of staking power and the narrative of decentralization.
Join our community to discuss and become stronger together!
Official Telegram community: https://t.me/aicoincn
AiCoin Chinese Twitter: https://x.com/AiCoinzh
OKX benefits group: https://aicoin.com/link/chat?cid=l61eM4owQ
Binance benefits group: https://aicoin.com/link/chat?cid=ynr7d1P6Z
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
