Enabling a Collaborative Collective to Improve Security in Web3

TL;DR

• To address the user safety within the web3 ecosystem, a mechanism reminiscent of Public Key Infrastructure (PKI) is proposed.

• Utilizing gateways and specific rules at the blockchain node level, offering an efficient method for various security vendors to deliver their services

• Recommendations for a web3 protection protocol in order to

  • Simplify security attestation indicators, enhancing the user’s perception of safety.

  • Standardize how security vendors provide their services, along with a specification for the value exchange between client and vendor.

  • Support user selection of security vendors and services through their JSON-RPC request security.

Recommendation to form an industry-wide working group to draft a Request for Comments (RFC) and develop reference implementations.

​​A prevalent challenge within web3 is user safety. How can users confidently deem a dApp secure, or be assured that blockchain operations will proceed as expected without unforeseen outcomes?

The ecosystem benefits from a variety of security vendors, providing a range of services. Typically, these vendors concentrate on client-side tooling, delivering their solutions directly to wallets or through add-ons. Is this the most efficient mechanism to make these services available to users?

This article discusses these concerns and suggests a pathway to a solution through the development of a web3 protection protocol.

The Perimeter of Security in Web3

In web2 security, digital asset owners leverage a vertically integrated infrastructure to exercise control over these assets. Conversely, web3 distributes its services across various entities and multiple service layers, some of which are DAOs, managing operations through blockchain-based smart contracts without traditional leadership structures.

As web3 decentralizes and broadens the security perimeter to encompass user devices, it inherently distributes security responsibilities, making the safety of the ecosystem reliant on the collective security practices of its users. This shift underscores a decentralized security model where the confidentiality and integrity of the digital assets  is as strong as the operational security (OpSec) of its individual participants.

To ensure users are equipped to navigate this decentralized environment, education is important. By understanding how to evaluate and trust reliable services, users can make more informed decisions, increasing their safety. It is necessary then to establish a clear model of trust, that not only aids users in identifying safer paths but also shares the responsibility of asset protection between product developers and users.

A Trust Mechanism Protocol

Product developers are currently the ones responsible for implementing strategies that enhance the user's perception of safety, focusing initially on UI elements and API messaging before expanding to encompass comprehensive measures including more rigorous security controls to further build trust.

A proposed mechanism may incorporate UI elements backed by API calls providing visible, understandable indicators of security and trustworthiness in web3 applications, akin to the lock icon in web2 browsers, which can significantly improve the user experience. Additionally, these API calls are to be executed to a node, therefore allowing users to efficiently query for attestations of objects and actors on the blockchain, establishing transparency in the web3 context by clearly indicating who endorses the security of what.

Take, for example, the use case of a smart contract developed by Alice, audited by Horace's Company, and subsequently certified by Maurice's Organization. A user will first inquire with Alice (or a service where Alice's feature is registered), asking, 'Who attests to this feature?' Alice will respond, 'Horace.' Then, the user queries Horace, 'Who attests for you?' Horace answers, 'Maurice.' Trusting Maurice, the user then establishes a trust chain for that new feature:

A trust verification service in the web3 space has the potential to evolve into a comprehensive tool, equipped with a wide range of modes and options. At its heart, however, it is crucial to focus on the essential aspect of the service: its ability to answer who endorses what. Once this fundamental question is addressed and a system emerges where attestations can be recursively verified, the logical progression is to develop a reputation system.

Web3 Enabled Security-as-a-Service

Vendor Categories

A diverse array of vendors plays a role in fortifying blockchain technologies against threats. These providers specialize in various protective services that significantly enhance the user’s perception of safety. Among these, phishing detection and social takedowns work to identify and mitigate fraudulent attempts that target users through deceptive practices. Similarly, on-chain detectors and alerts monitor blockchain transactions in real-time, providing immediate notifications of suspicious activities to prevent potential threats.

Further securing the blockchain, transaction simulation services test the robustness of transactions before they are executed, ensuring they are safe from vulnerabilities. Malicious smart contract detection focuses on identifying potentially harmful contracts that could undermine the network's integrity. Additionally, secure nodes and post-transaction signing security enhance the authenticity and integrity of transactions even after they are included in the blockchain. Understanding the specialized services and strengths of each category allows stakeholders to make informed decisions toward a more secure infrastructure.

Gateways and Rules for a Blockchain Node

To interact with the blockchain, clients issue a JSON-RPC API message to a node connected to the peer-to-peer network. If the operation involves a writing operation, this node relays the request across the network. A sequencer node then picks up this writing request, incorporating it into a valid block. Once included, this block is propagated throughout the network.

Security for writing requests is mostly handled on the client side. For instance, the MetaMask wallet protects its users from visiting malicious domains by leveraging the eth-phishing-detect list. Consequently, whenever users attempt to open a domain identified as malicious by this list in their browser, they receive a notification. This prevents them from interacting with the site.

Web3 messages, capable of carrying value, offer vendors the opportunity to adopt a more granular approach to service exchanges, paving the way for the development of marketplaces for security providers and diverse models for layering threat intelligence. These models specify which actor receives what information and when. A paradigm shift is required to operate within this scheme: it is crucial that services are deployed at the blockchain node level, rather than on the client side.

In the proposed model, a gateway serves as an optional module installed by the operator of a blockchain node, designed to facilitate secure interactions between clients and the blockchain relayer. As the direct recipient of the client's JSON-RPC API call, this unit plays a critical role in ensuring the safety of messages by enforcing rules on them. These rules, which include criteria such as the identification of malicious addresses, enable the gateway to effectively apply specific services.

Each set of rules is associated with a service offered by a specific vendor, adhering to the web3 protection protocol. This standard compliance achieves two key objectives: ensuring standard compatibility across offerings and facilitating a revenue model for the vendor by leveraging web3's capabilities for value exchange.

This model is flexible, suitable for both default RPC providers and decentralized infrastructure coordinated by routers. It also thrives in a marketplace environment where clients have the freedom to select their provider URL.

The availability of service options not only enhances the ecosystem's security but also paves the way towards a genuinely decentralized security landscape. This variety encourages innovation and resilience, allowing a tailored approach to security that empowers users to choose the solution that best fits their needs.

Enhance the RPC Transaction Message for Rules and Parameters

As users have the option to choose their RPC provider, the protocol must allow them the ability to specify which security services they wish to leverage. For example, they should have the capability to choose whether to use the service provided by vendor Horace that verifies if the recipient of a transaction is on a list of malicious actors.

Additionally, users should be enabled to send extra metadata related to the transaction, such as the domain or domains involved, and crucially, choose the phishing domain service for verification purposes. This information should be added to the HTTP header of the JSON-RPC message, as including it as an additional parameter within the JSON could result in undefined behavior.

Protocol Recommendations

Recommendation 1

Develop a protocol to simplify security attestation indicators, enhancing the user safety.

This approach simplifies user understanding and trust in the security measures implemented, encompassing various levels of attestation (e.g., audited, reviewed, built) and diverse identification methods (e.g., blockchain address, domain), always accompanied by a cryptographic signature. The protocol for API queries should be straightforward, with the complexity managed by the UI, such as displaying a recursive chain of trusts. To simplify storage, consider using only the ID of the network storage object that contains the attestation and its signature.

Recommendation 2

Develop a protocol to standardize how security vendors provide their services, along with a specification for the value exchange between client and vendor.

Security vendors will provide their services via API integration, enabling gateways (blockchain node reverse proxies) to implement a set of rules to allow or reject JSON-RPC messages from clients. This protocol should include a clear, chain-agnostic method for value exchange (e.g., through smart contracts or standardized payment APIs), ensuring that providers are compensated for their services.

Recommendation 3

Develop a protocol to support user selection of security vendors and services through their JSON-RPC request security.

Users can specify within their JSON-RPC requests to gateway-secured blockchain nodes the specific rules they wish to enforce. As a use case example, in scenarios involving domain phishing, users have the option to select a phishing domain protection service within their message. Alongside this selection, they will also send a list of domains (or domain hashes for enhanced privacy) to be verified.

Establishing an Industry-Wide Working Group for Web3 Security

It is recommended to establish an industry-wide working group to produce a Request for Comments (RFC) and reference implementations for a web3 protection protocol. This initiative will incorporate the recommendations discussed in this article, aiming to guide both established and emerging participants in adopting these security measures.

A potential result of this approach is a vibrant ecosystem where node providers compete to incorporate the most proficient security services into their gateways as a set of rules. This competition encourages vendors to specialize and continuously improve their offerings. Streamlining this economy through a web3-powered system for value exchange further empowers decentralization.

Footnotes:

• Clancy, C., Norman, M., & Wijesinghe, S. (2022). Securing Web3 and Winning the Battle for the Future of the Internet. MITRE. https://www.mitre.org/sites/default/files/2022-09/pr-22-2754-securing-web3-winning-battle-for-future-internet.pdf

• While the security of smart contracts and blockchain nodes is equally crucial, the focus in this article is on elevating the perception of safety for users operating their wallets.

•  https://ethereum.org/en/developers/docs/apis/json-rpc/

•  https://metamask.io/

•  https://github.com/MetaMask/eth-phishing-detect