[IMPACT] Please describe your proposed solution.

Problem

Name systems - as Charles Kozierok poignantly notes in *The TCP/IP Guide* - occupy a peculiar place in information technology. On one hand, they are superfluous; there is no technical requirement that human-readable *symbolic names* exist in order for networks to operate reliably. On the other hand, they are essential; without a system for resolving symbolic names into machine-readable addresses, only the tiniest of networks would be practically usable.

The Domain Name System (DNS) - by far the most widely used name system today - has, for nearly four decades, facilitated the process of resolving symbolic names into machine addresses. In many ways, DNS is an astounding technical achievement. By supplanting the primitive host table name systems that powered the early internet, DNS surely enabled the rapid growth of the internet in the last decade of the 20th century.

As DNS approaches its 40th birthday, however, it is prudent to wonder whether the name system that has served internet users so well for decades is showing its age: Is DNS the best option for powering the next 40 years of the evolution of the internet?

There are reasons to doubt that it truly is up to the task:

SECURITY: Flawed assumptions in the design of the DNS protocol have enabled a variety of attacks (cache poisoning, subdomain takeover, etc) that have persisted to this day. Mitigating these attacks has often required ad-hoc changes to the protocol.

TRANSPARENCY: The nature of the DNS protocol makes it extremely difficult to gain information on the total state of the system, and no complete history of the state of the system exists. This greatly increases the difficulty of threat detection and analytics, which require knowledge of the history of state changes in the overall system. For example, a malicious actor may compromise a domain owner's credentials to associate the domain name with a malicious IP address, and then revert the change - a process that is practically invisible to the public. Archives of the historical state of DNS exist but are necessarily partial and typically not available to the public.

PRIVACY: Vanilla DNS queries have no privacy mechanism at all. Use of the protocol fundamentally requires that clients trust their DNS server's operator to protect potentially sensitive information contained in the queries. While some DNS server operators may do so, a large number of DNS servers assuredly do not. This poses a real risk to users when their DNS server operator engages in collusion with bad actors - e.g. an authoritarian regime colluding with an ISP could easily use DNS queries to identify members of gender or sexual minority groups and subject those members to violence or oppression. Even in a less dire context, DNS query data can be used to fingerprint users and sell their data without their consent.

CENSORSHIP: Domain owners (who are in fact owners-in-name-only) are fully subject to the whims of their parent domain's DNS server operator. A malicious operator (or one subject to coercion by an authoritarian government) can effectively erase an owner's resources from the public internet.

CENTRALIZATION: The nature of the DNS protocol naturally leads to a situation in which a domain owner is effectively at the mercy of the owner of their parent domain. Ordinary domain owners have no effective grounds of appeal if the operator of their parent domain - who in many (though not all cases) is a for-profit corporation - decides to revoke or fail to renew their domain registration.

It is worth repeating that interacting with the DNS protocol is effectively obligatory to make use of the internet - a practical necessity for modern life in much of the world. There are no alternative protocols in wide use, and it is extremely unlikely that the existing DNS protocol can be modified to ameliorate the problems enumerated above.

The problems enumerated above are compounded by the fact that DNS is thoroughly entrenched in modern web infrastructure. An alternative name system that addresses these problems but provides no migration path from DNS is practically guaranteed to fail - DNS simply has too much inertia to be replaced in one stroke, no matter how superior the replacement may be on paper.

Solution

I: DeNS Overview

NOTE: This is a very general overview of the DeNS protocol, which is provided here to contextualize the much more modest first step we are seeking funding for in this proposal. This is not meant to be an exhaustive specification or detailed technical summary.

For the reasons just mentioned, the transition away from DNS must happen gradually if it is to happen at all. Here, we propose to take the first steps towards DeNS - a decentralized name system, powered by blockchain technology, which addresses the privacy and security shortcomings of DNS while providing a migration path. Broadly, we envision DeNS as a name servicer with two key attributes:

Centrally Located Registries of Name -> Resource Record mappings, which are practically necessary to avoid overlapping names and facilitate efficient query resolution. (In this respect DeNS is similar to DNS.)

Decentralized Control of authorization and the registration process. Note that here, Decentralized Control means that no single entity possesses the authority to unilaterally alter the registry, which can be modified only in accordance with policies that have achieved stakeholder consensus.

The nature of distributed ledger technologies additionally ensures:

• An immutable, public, and transparent record of both *the current state* of the system and the *total history* of the system's state.
• Built-in privacy: Because the current state of the name system is recorded on a public ledger, a privacy-conscious individual or organization can easily maintain their own copy of the state of the system, thereby *eliminating the need to trust third-party server operators*
• Inherent Security: The resource address associated with a domain owner's symbolic domain name can only be updated by an entity that possesses the owner's private key, greatly reducing the likelihood of successful domain hijacking attacks (which in the context of DNS can be performed by compromising an email account or upstream server operator).

The DeNS protocol consists of two parts:

1. An autonomous governance mechanism - the operator of each segment of the total namespace is a type of Decentralized Autonomous Organization (DAO) that has clear and strong incentives to maintain the reliability of the overall system.

2. A specification that outlines the standards and requirements that operators must conform with to participate in the protocol.

II: Integration Path

As noted above, a DNS alternative that does not provide an integration path from DNS will almost assuredly fail. In this proposal, we are only seeking funds to implement the first steps towards DeNS. Those steps amount to mirroring existing DNS records on an immutable ledger in order to allow privacy-conscious individuals to opt out of the DNS protocol without opting out of internet use.

Concretely, we are seeking funding to implement and operate three core components that will demonstrate the viability of blockchain-based name resolution:

1. A traditional caching DNS server (configured with maximal security and privacy options) which we intend to modify and make available to users in order to ingest DNS records for storage on the blockchain.
2. A smart contract and related library code that stores DNS records on the blockchain (or, alternatively, that stores a hash of DNS records along with an unambiguous reference to the location of those records on IPFS or another decentralized storage solution - see below for more details).
3. An “offline” DNS resolver, powered by an efficient Cardano chain-indexer (likely Kupo) that reconstructs the Name -> Record map and allows resolving domain names to addresses without any DNS servers or queries.

Taken together, these three components will not only suffice to show that the core technical ideas are viable, but will provide a valuable service: Individuals who require (or simply desire) a high degree of privacy will be able to immediately make use of our “offline” Cardano-powered resolver to avoid surveillance via DNS - because these users never send any DNS queries, there is simply nothing to surveil.

The upshot of these core components is that they suffice to provide both an immediate integration with many existing systems that require DNS in the short term and mechanism for deprecating DNS over the long term. Should it eventually occur that a majority of internet users and systems migrate to either an “offline” resolver or a traditional DNS server that treats on-chain records as authoritative, the entity that manages on-chain records will have effectively wrested control of domain names away from the organizations which, at present, administer DNS. The potential to usurp DNS over the long term is one reason why we do not attempt to integrate with DNS in the same way as other blockchain-based name systems; while it is certainly possible to delegate control over domains to entities which can prove ownership of the domain via DNSSec certificates, we believe that a name system which does so is unlikely to ever replace DNS. If your name service delegates authority to existing domain operators and resellers, you have effectively conceded that your system is second-class at best.

Important note: We feel obligated to clarify that DeNS is not a competitor to any existing decentralized name system on Cardano (or any other blockchain). During this phase, our sole aim is to demonstrate the viability of a general method for blockchain-based name resolution that can be extended to support almost any name resolution protocol. (Although this fact is not widely known, DNS itself was originally designed to support a number of distinct address protocols, and we will simply borrow the unused mechanism for doing so.) The same strategy that we employ to “subsume” DNS under DeNS can be employed to “subsume” other name systems without usurping them. The governance contracts that we will implement in future phases of this project require a diverse set of stakeholders who have a strong interest in both decentralization and the long term success of the system - we do not intend to ourselves become regents of a new root domain. Existing blockchain name service operators are natural candidates to participate in governance of the DeNS system, and we will, in future phases, extend invitations to all technically-compatible name-services to participate in shared governance.

Ultimately, our goal is to construct a decentralized root domain that is governed collectively by the stakeholders, thereby solving a network-effect problem that, we believe, hampers adoption of DNS alternatives today. Existing blockchain-based name systems in effect act as both root domain and TLD operators of their own name-universe. While we believe that decentralized control is beneficial, this state of affairs fragments the ecosystem and decreases the chance that any one solution will succeed in supplanting DNS. A hierarchical set of authoritative records is perhaps the most essential feature enabling DNS’s success. By uniting existing DNS alternatives, we aim to support a centralized hierarchy of records that is located in one place but controlled collectively by many stakeholders. We believe that this approach will in fact greatly benefit existing blockchain-based name services and enable a high degree of decentralized and autonomous collaboration.

III: Future Work

Upon the successful completion of this phase of the DeNS project, we will have produced the essential technical core required to implement the resolution mechanism of our name system. Future phases of the project will aim at designing and implementing the governance contracts for administering the DeNS root domain, and producing detailed specifications concerning the operation of the protocol.

However, we must note that our goal cannot be achieved by technical work alone. Consequently, while this initial phase has a pure technical goal, subsequent phases will require outreach and collaboration with potential stakeholders of our protocol. We intend to reach out to operators of existing blockchain name systems, standards organizations, and other parties to build an organization that will enable the growth of a less-centralized and more privacy conscious internet.

Market

While we intend that later phases of the DeNS project will give rise to a new market for domain names, we are requesting Catalyst funds because we do not believe that there is a way to monetize the initial migration path from DNS, and therefore we do not have a market (in the financial sense) in mind for this initial phase.

In a more general sense, the market for our project consists of anyone who wants a higher degree of privacy than existing web infrastructure can provide.

[IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

Intended Challenge – Development & Infrastructure

Challenge Statement – “What research, tools or software can improve the developer ecosystem or infrastructure to make it easier to build and scale on the Cardano blockchain?"

How does this proposal improve the developer ecosystem?

Our blockchain-based DNS resolver will decentralize domain name resolution, enhancing privacy and security for dApp and improving Cardano's utility. It will benefit developers and the broader community by:

Boosting Efficiency: It simplifies blockchain navigation and data access, streamlining application development on Cardano.

Enhancing Security: It offers a secure, privacy-centric method for DNS resolution, contributing to the safety of applications built on the Cardano blockchain.

Stimulating Innovation: Our novel approach to DNS resolution can inspire fresh, innovative applications within the Cardano ecosystem.

Conserving Resources: Developers can avoid creating their own secure DNS resolution mechanisms, saving time and resources.

[IMPACT] How do you intend to measure the success of your project?

For this phase, we will consider the project a success if it results in a blockchain-based “offline resolver” that can be used to resolve names to addresses without leaking any sensitive user data. (While we would like to measure success by the number of users who make use of our “offline resolver”, our project, by design, precludes any obvious way of counting or identifying users.)

[IMPACT] Please describe your plans to share the outputs and results of your project?

All source code outputs of our project will be published under a free and open source software license and made available to everyone. All non-code document outputs will be published under a free documentation license. If our budget allows us to do so, we will offer binary bundles of our “offline resolver” for as many platforms as we can in order that non-technical users might benefit from our project.

[CAPABILITY/ FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability?

We believe that we are in an excellent position to deliver the project with our requested budget. Our DNS server component can easily be implemented by modifying one of several existing options, which can be done with relative ease. The “offline resolver” component is essentially a small layer over a Cardano chain indexer, which we do not expect to have difficulty implementing. The largest unsolved problem we face is determining the most efficient way to store the Name->Address maps on the chain (or on some decentralized storage service with an on-chain integrity mechanism). Admittedly, this requires some research and experimentation, but we are experienced Cardano developers who are well equipped to carry out the requisite research and experimentation quickly and efficiently.

[CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you validate if your approach is feasible?

The main goals of this phase of our project are:

1. Create a mechanism to ingest DNS records. Initially, we intend to do this by operating a modified DNS server - though we note in passing that we intend to petition ICANN for access to the zone files for gTLDs, which would be a very useful supplement but is not ultimately necessary.
2. Implement a decentralized storage mechanism for the DNS records we ingest.
3. Implement an “offline resolver” that can be used to opt out of interacting with DNS servers entirely by retrieving records stored via the decentralized storage mechanisms.

See the previous section for a discussion of the viability/feasibility of these components.

[CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

Milestone 1 - DNS Record Ingestor / Record Storage Research (~140 dev hours / one month) : Modify an existing caching DNS server to store query results in a persistent form. Conduct research on decentralized storage of records (attempt to determine maximally efficient way to store records on-chain, calculate cost of onchain vs offchain/IPFS storage, decide which approach is best).

Milestone 2 - DNS Record Storage Solution (~140 dev hours / one month) : Design and implement Cardano or IPFS storage of records / integrity mechanism, including all smart contracts and utilities necessary.

Milestone 3 - Blockchain-based Resolver (~140 dev hours / one month): Design and implement “offline resolver” that integrates with the record storage solution and integrate it into at least one operating system. (This may be simple integration, i.e. writing a hosts file, or something more substantial depending on research results / budget requirements). Produce documentation for the offline resolver. Release the offline resolver & source code to the public.

[CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone.

Milestone 1 - DNS Record Ingestor / Record Storage Research: The outputs of this milestone are an operational DNS server modified for record ingestion as outlined above and a document that outlines a general specification of the record storage solution.

Milestone 2 - DNS Record Storage Solution: The outputs of this milestone are an implementation of all onchain and offchain components necessary for the decentralized record storage solution.

Milestone 3 - Blockchain-based Resolver: The outputs of this milestone are a working implementation of the “offline resolver” that integrates with at least one operating system, and related documentation.

[RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

We estimate that each milestone will require approximately 140 hours of development time.

3 Milestones * 140 hours = 420 hours

Plus ~20% change budget = 510 hours

Subtotal: 510 hours @95/hour = $48,450 USD

Operational expenses: $5,700 USD

Total USD: $54,150

Grand Total (@ rate $0.21 USD / ADA): 257850 ADA

**In the interest of full transparency, please note we have applied a conservative USD/ADA exchange rate in pricing this proposal. This is to ensure our operations remain stable regardless of market conditions. Although we firmly believe the future of Cardano is bright, we recognize the price of ADA and all cryptocurrencies is inherently volatile. Our financial obligations are denominated in fiat. Most importantly, this includes the salary of our engineers whose hard work makes projects like this possible.

In the unlikely scenario of severe negative price movement beyond our forecasted rate, it is possible that MLabs may need to temporarily suspend work on this proposal until the market recovers. Rest assured, this decision would be made solely to protect our business's long-term viability and never taken lightly.

We appreciate your understanding and support, and we are excited to see what we can achieve together.

[RESOURCES & VALUE FOR MONEY] Who is in the project team and what are their roles?

MLabs

MLabs has quickly become one of the premier development firms in the Cardano Ecosystem. We are an IOG Plutus Partner and work regularly with IOG to develop the Cardano blockchain and ecosystem. Our team is composed of talented developers who have helped build community projects such as:

• Liqwid
• SundaeSwap
• Minswap
• Optim
• Many others

Through our work with early-stage projects, we have one of the largest groups of Haskell/Plutus developers in the community.

Website: <u>https://mlabs.city/</u>

Core Team

Sean Hunter:

Sean is an engineer with extensive Cardano smart-contract development experience. He has implemented and audited multiple complex projects written in both PlutusTx and Plutarch. Sean's functional programming journey began as an offshoot of his academic interest in formal logic, and to this day he maintains a strong interest in type theory (with a special interest in row types and their applications).

Drazen Popovic:

Full-stack Cardano distributed application (dApp) developer and auditor, working on several Cardano dApps that span Haskell, Purescript, Rust and Nix language environments. Worked on decentralized protocols based on the Cardano blockchain including decentralized exchange, synthetic assets, oracle protocols and programmable money. In particular, he was the technical lead on the <u>Cardano Open Oracle Protocol</u> and was responsible for design and implementation.

Technical lead on the <u>LambdaBuffers</u> project, which is a novel toolkit for sharing types between different languages. Led the design and implementation which included common compiler topics such as type checking, type class resolution and code generation into various languages.

Less notable, but mention worthy, a maintainer of a <u>Purescript Bridge</u> fork (now deprecated in favor of LambdaBuffers) and a contributor to <u>Cardano Transaction Lib</u> Purescript library which is one of the foundational tools in the Cardano ecosystem.

[RESOURCES & VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

On a technical level, we believe that the open-source outputs of our project will likely be useful for other Cardano-based name systems. Additionally, because we intend to explore strategies for storing this data on-chain, we believe that the results of our research in that area could prove generally useful.

The most significant benefit to the Cardano ecosystem, however, is ultimately not a technical benefit: For years, blockchain evangelists have proclaimed that distributed ledger technologies will help to bring about a decentralized and privacy-conscious future internet. While these technologies have certainly given rise to an abundance of decentralized financial systems, they have not delivered solutions with concrete benefits for typical internet users who may have no interest in decentralized finance. Even in this early phase, our project will deliver concrete benefits for such users. Admittedly, our project is only one small first step towards a decentralized and privacy-conscious future for the internet, but we believe that success here will greatly strengthen the case for a broader application of Cardano’s blockchain technology.

Finally, we note that recent disputes concerning the classification of cryptocurrencies in general (and ADA in particular) as securities hinge, in part, on whether these currencies are primarily investment vehicles. We believe that our project’s success would constitute a strong argument against that classification by demonstrating Cardano’s potential use as a core piece of internet infrastructure.