blockful - service provider reports

[blockful]

We’ll use this thread to post all our past and future quarters updates under the scope of ENS service provider.

Q1/Q2 report

Summary

Our journey began with our proposal to the ENS DAO, where we outlined our vision for enhancing ENS. The challenge we decided to first work on was related to off-chain and L2 resolvers. After Vitalik’s tweet, it became clear that it was important.

Our approach is to create solutions and standards that enhance the whole ecosystem and do not fragment it by competing with other platforms. We want to support both existing and new builders.

Overview

Implementing a standard, not creating a competing platform. Let’s understand what that means:

Namestone is a service that creates and manages off-chain subdomains through an API. Data is stored in a database. Before performing any write operation, you should read their docs and know how to communicate with the API.

This is true for every other subdomain issuer you see: cb.id, base.eth, linea.eth, namespace, etc.

By having projects that use and contribute to this standard, we can build applications that can interact with all of these providers without needing to understand the implementation details for each one.

Success in this initiative means having significant players adopting the standard and having the ENS dapp and ensjs implementing the ENSIP.

Transparency: build in public

This is one of blockful’s core values. Not only are the repos open-source, but so are the task management, planning, and track records. You can see all the tasks done in the first semester, with all card descriptions, related pull requests, team discussions, and estimates keeping all the development and research contracted by the DAO accountable.

Foundation and Research

Following the proposal, we dove deep into research on Offchain ENS considering it would bring the most value to the ecosystem. Our team studied the intricacies of CCIP-Read (EIP-3668) implementation and investigated the potential of Cross Chain Write Deferral (EIP-5559). This foundational research shaped our understanding and approach to off-chain solutions.

We then moved into the development phase, creating the initial version of our Offchain Resolver. This was a significant step forward, translating our research and design into a functional implementation. During this process, we encountered a challenge with the Optimism integration due to updates in EVM Gateway data verification (addition of Fault Proofs on OP). We then pivoted our focus to Arbitrum, ensuring continued progress in our off-chain resolver development.

Good standards and research can only be done if you get hands-on, so we explored each off-chain resolver step to understand improvement opportunities.

Technical Contributions

External resolver (repo)

The goal of the external resolver repo is to be the industry standard for off-chain domains (using DBs and L2s), implementing the new ENSIP and past ENSIP support, with interoperability as the core value. This led us to the development of our own version of the CCIP-Gateway based on the Chainlink implementation as well as contract interfaces that made easier the implementation for multiple contexts.

We then launched our first version of the Arbitrum Resolver with CCIP-Read support, followed by the implementation of the Arbitrum Verifier based on the EVM Gateway. This further solidified our off-chain resolver’s capabilities within the Arbitrum ecosystem.

Go ENS (pull request)

Our team contributed to the Go-ENS library, adding support for CCIP-Read and ENSIP-10 to improve the broader ENS ecosystem. Also, a public bounty of 0.5 ETH helped prioritize it.

User-Facing Developments (repo)

Recognizing the importance of user accessibility, we began the development of the nameful dapp. This initiative aimed to bring our off-chain solutions closer to end-users, making them more accessible and user-friendly, as well as serving as proof-of-concepts for both the off-chain reading and writing standards we’re developing.

Our work on the Database Resolver saw several key achievements. We completed the EIP-5559 implementation, achieved the first subdomain registration using this protocol, and successfully deployed the resolver to the Sepolia testnet. These milestones marked significant progress in our off-chain capabilities.

To enhance user interaction with our solutions, we launched the domain management UI on nameful. This interface made it easier for users to manage their ENS domains using our off-chain features.

Expanding Capabilities

Our Arbitrum integration reached new heights as we deployed the Arbitrum Resolver to Sepolia testnet and registered the first subdomain on Arbitrum through EIP-5559. These achievements demonstrated the practical application of our off-chain solutions in a Layer 2 environment.

We then enhanced our Gateway functionality by implementing support for writing multicall. This improvement increased the efficiency of our off-chain operations, allowing for more complex interactions.

In a significant step towards bridging on-chain and off-chain capabilities, we registered the first 2LD on L1 with records stored in the database. This milestone showcased the seamless integration between traditional ENS infrastructure and our off-chain solutions.

Standards and Specifications

As already mentioned, the major purpose of the external resolver implementation is establish a standardized flow for managing offchain writing in the ENS ecosystem, creating an universal interface that can be applied across various scenarios of offchain domain storage.

The key value the standard brings is the communication with the L1 redirecting the request to the given destination by relying on the EIP-5559. The complete flow can be visualized on the following diagrams:

L2 subdomain registering [WIP]

Database subdomain registering

During the development of the nameful dapp, we faced a challenge in integrating offchain domains with existing ENS components. This led us to propose improvements to the existing ENSIP-16 (Offchain Metadata API). Our proposal aims to enhance the developer experience by reducing the number of requests required to fetch all the data of a given domain. The proposal is currently under discussion in the ENS community, and we’re actively gathering feedback.

Finally, we drafted the first version of what we’ve called Wildcard Writing ENSIP, a standard interface that standardizes the off-chain writing methods. This contribution, which has yet to be posted on the ENS forum, aims to achieve the interoperability we mentioned at the beginning of the report.

Community education

As an initiative to educate and involve the Latin American community in the ENS and ETH ecosystem, we conducted a workshop at the ETH Samba hackathon in Rio de Janeiro. The workshop showcased major ENS features and provided a step-by-step guide on how to set up a domain.

More to come on that in the following months.

Governance security

As mentioned in our proposal, we are reviewing the call data for each executable proposal. EP 5.12 was the only one that wasn’t possible due to its size and details. We will create a more official report platform through a forum thread to make sure this work is accountable.

Other contributions not related to service provider scope

Being closer to ENS as an organization allowed our research team to also analyze the governance in depth (which is our primary expertise as blockful), which led to research that resulted in the creation of the Security Council. We’re finishing a blog post that will outline more of this work for securing the DAO.

Looking Ahead

As we continue our journey, we remain committed to:

• Refining and formalizing our off-chain standards based on community feedback.
• Working on the adoption of these standards with major players, ENS app and ENSjs.
• Expanding partnerships and integrations to increase ENS adoption.
• Understand what brings the most value for ENS and the community, adapting our protocol research and scope of work for optimal value generation.

We’re grateful for the support of the ENS DAO and community throughout this journey. We look forward to further collaboration as we work together to enhance and expand the ENS ecosystem.

[5pence.eth]

Good update. Thanks @blockful.

@blockful

Governance security

As mentioned in our proposal, we are reviewing the call data for each executable proposal. EP 5.12 was the only one that wasn’t possible due to its size and details. We will create a more official report platform through a forum thread to make sure this work is accountable.

This is a great service to the DAO.

Meta-governance is encouraging proposals to be clear, predictable, and have a uniform matching post in the forum that can be read and commented on before the proposal goes live.

It would be great if we could establish an expectation that on all executable proposals, Blockful will comment on the respective forum post with your review of the call data.

[blockful]

Thanks for the feedback, Spence! It’s a great suggestion, and we’ll do that or a delegation platform where we post reviews of EPs and reasoning for votes.

[blockful]

Q3 Report

Summary

Building on our previous achievements, we’ve made significant progress in implementing and standardizing off-chain and L2 resolvers. We continue to prioritize creating solutions and standards that enhance the user experience and developer experience across the ENS ecosystem.

Major Updates and Achievements

ENSIP: Wildcard Writing Interface

We’ve drafted an ENSIP that proposes a standardized Wildcard Writing interface for registering and managing offchain domains within the ENS ecosystem.

Key aspects of the ENSIP include:

1. Standardized Methods: The proposal outlines methods for domain registration, transferring, and setting records, ensuring a consistent approach to offchain domain management.
2. L1 Resolver as entrypoint: The specification uses the Resolver deployed on Ethereum as an entry point for offchain calls, redirecting these calls to the respective destination (L2 or database). The same approach was used by the well-established CCIP-Read.
3. Support for Database and L2 Implementations: The ENSIP provides considerations for both database and Layer 2 implementations, allowing for flexible offchain storage solutions.
4. Key Functions:
   • registerParams: For obtaining registration parameters
   • register: For registering subdomains
   • transfer: For transferring domains
   • multicall: For batch operations on ENS records
   • commit: For enabling the commit/reveal strategy for offchain subdomain
5. Integration with existing standards: The proposal leverages EIP-5559 for offchain writing and maintains compatibility with existing ENS components.

This ENSIP represents a significant step forward in standardizing offchain domain management within the ENS ecosystem. It provides a framework that will enable consistent implementation across various offchain storage solutions, improving interoperability and user experience.

We aim for going from a protocol-based client implementatation to a standardized version of it, dramatically reducing the complexity required from the client.

Integration with Major Ecosystem Players

A standard has no value if there is no adoption. Our latest efforts are around validating and building it with the ecosystem:

• Coinbase
• Namespace
• Linea
• ENS Labs

The integration process is ongoing, at various stages, between feedback and testing. We’re focusing on maintaining consistency with existing ENS standards while adapting to the unique features of each platform, exploring potential synergies between different approaches to create a more robust and versatile interface.

Deployment of ENS Contracts on Arbitrum

We’ve successfully deployed the ENS contracts on Arbitrum as a proof of concept for the Wildcard Writing L2 implementation. This interim step marks a significant milestone in our efforts to extend ENS functionality to Layer 2 solutions and serves as a valuable testing ground. The lessons learned from this implementation will be invaluable in ensuring these standards can be used in different use cases, players, and can also be integrated into the upcoming ENS architecture.

Key aspects of this deployment:

• Successful implementation of ENS contracts on Arbitrum
• Validation of EIP-5559 L2 implementation in a real-world scenario
• Establishment of a foundation for future L2 and database integrations

Indexing of ENS Events on Arbitrum

We’ve successfully indexed ENS events on Arbitrum, which are now used for the ENSIP-16 Metadata API for Arbitrum. This development enhances our ability to retrieve off-chain ENS data efficiently. By indexing events on Arbitrum, we’ve extended the functionality of the Metadata API to L2 environments, improving the client’s data fetching of offchain domains.

Implications of this achievement:

• Enhanced data retrieval capabilities for L2 implementations
• Enable the nameful (our dapp) integration with domains stored on Arbitrum

User-Facing Developments

The nameful dapp has seen substantial improvements, now handling both L2 and database registering and management of subdomains. This enhancement provides users with a more comprehensive and flexible tool for managing their ENS domains across different environments.

Key improvements include:

• Support for L2 subdomain registration and management
• Standardization of the database-stored domains with the same interface as the L2
• Enhanced user interface for managing domains across different storage solutions

Community Education

We conducted a meetup and workshop about Web3 and ENS at the Curitiba Blockchain Weekend. This initiative continues our commitment to educating and involving communities in the ENS and Ethereum ecosystems, with a particular focus on expanding our reach in Latin America.

This initiative was made possible thanks to the Gitcoin round funding. The whole summary of the event can be found at the Blockful’s blog.

Key highlights:

• Introduced ENS concepts to a broader audience
• Provided hands-on experience with ENS tools and interfaces
• Debate regarding governance
• Gathered feedback from potential users and developers in the Latin American blockchain community

Looking Ahead

Our current focus is on integrating our developed standards with major players’ implementations and gather feedback from the ENS community. This effort aims to increase adoption of our standardized approaches and further unify the ENS ecosystem.

We remain committed to:

• Refining and promoting the off-chain and L2 standards based on community feedback and real-world implementation experiences.
• Expanding partnerships and integrations to increase ENS adoption.
• Further developing and promoting the ENSIP for Wildcard Writing interface.
• Enhancing our user-facing tools, like the nameful dapp, to provide seamless management of ENS domains across different storage solutions.

We’re grateful for the ongoing support of the ENS DAO and community. We look forward to further collaboration as we work together to enhance and expand the ENS ecosystem.

[blockful]

Q4 Report

Summary

In this development cycle, we’ve focused on making ENS domains more powerful and easier for everyone to use. Here’s what’s new:

As highlighted during frENSday by Jeff Lau, most ENS domains today operate through off-chain systems, showing how crucial this technology is for ENS’s success. Building on this foundation, we’re introducing new standards to make domain management more seamless and user-friendly.

First, we’ve created a simpler way for doing transactions between different chains by establishing a behavior that the contracts should implement, making it easier for dapps to integrate regardless of the use case. We named it Operation Router because it acts as an actual router, redirecting the request to the given contract or API.

Second, we’ve applied this router strategy to the ENS use case. With the standard, any dapp can support domain management by following the proposed flow, features that currently require users to access multiple dapps to manage their offchain domain. The standard adoption means that the ENS dapp would be able to manage any kind of domains with the same interface it handles Ethereum ones.

We’ve also launched ens.rent, allowing domain owners to rent out their unused domains easily and securely. This opens up new opportunities for both domain owners to earn from their domains and for others to use ENS domains temporarily without having to buy them outright.

These improvements make ENS more accessible and valuable for everyone, helping it grow from a simple naming system into a more powerful and flexible platform for the future of the internet.

Operation Router EIP Release

The Operation Router EIP represents a significant advancement in offchain data management standards. This implementation is the result of multiple iterations with the ENS community and Nick Johnson (@arachnid) aiming to improve the existing strategies for offchain transactions by transforming the traditional two-transaction flow proposed by the ERC-5559 into a streamlined view call and transaction system.

The standard centers around the getOperationHandler view function, effectively turning the any contract into a router that redirects operations to either onchain or offchain handlers. This standalone solution extends beyond ENS protocol applications, prompting its development as an EIP to serve as the foundation for the proposed ENSIP. In the ENS ecosystem, the resolver deployed to Ethereum would serve as the entrypoint for all the transactions related to offchain domains.

Wildcard Writing ENSIP Update

The Wildcard Writing ENSIP has been enhanced to leverage the Operation Router infrastructure. The latest version in the ENSIPs GitHub repository introduces optimized write operations across the ENS ecosystem.

The specification has been enhanced to support two distinct operational flows. The onchain flow facilitates direct interaction with smart contracts deployed across different layers, while the offchain flow manages database operations through a secure gateway system. This dual approach ensures efficient data management while maintaining strong security guarantees through typed signatures.

There are multiple interfaces that can be inherited by any contract creating a opt-in architecture where each domain provider is able to provide features as intended, e.g. enabling the commit/reveal strategy for registration or providing ways for domains to be transferred.

struct RegisterRequest {
    bytes name;
    address owner;
    uint256 duration;
    bytes32 secret;
    address resolver;
    bytes extraData;
}

interface OffchainRegister {

    struct RegisterParams {
        uint256 price;
        bool available;
        address token;
        uint256 commitTime;
        bytes extraData;
    }

    function registerParams(
        bytes calldata name,
        uint256 duration
    )
        external
        view
        returns (RegisterParams memory);

    function register(RegisterRequest calldata request) external payable;

}

interface OffchainTransferrable {

    function transferFrom(
        bytes calldata name,
        address owner,
        address newOwner
    )
        external;
}

interface OffchainCommitable {

    function makeCommitment(RegisterRequest calldata request)
        external
        pure
        returns (bytes32 commitHash);

    function commit(bytes32 commitment) external;
    
}

ENS Rent Platform Release

ens.rent introduces a comprehensive rental system supporting both wrapped (ERC1155) and unwrapped (ERC721) ENS names. Built on BaseRegistrar, NameWrapper, and ENSRegistry components, the platform features per-second pricing, customizable duration parameters, and automated custody management.

Implementation Progress

ENSjs Updates

Although the Wildcard Writing standard still under review process, the team has implemented Wildcard Writing functionality in the ENSjs fork repository, expanding the JavaScript library’s capabilities an making it easier for the community adoption. This implementation provides developers with enhanced tools for managing write operations across different layers of the ENS ecosystem, ensuring backward compatibility.

The end goal is to have the standard being handled on every call that reverts with the specified error, redirecting the request to the given source, the same way the clients do for the CCIP-Read.

Throughout the research of the ENSjs implementation, the team has found an opportunity to contribute to the library by implementing a subdomain registration functionality.

DAO Proposals

The ENS DAO proposals calldata validation implementation strengthens governance process security and reliability through comprehensive validation procedures.

Future Development

Current development priorities include:

1. Operation Router protocol optimization based on Ethereum community feedback
2. Provide a clear path for the domain providers to adopt the Wildcard Writing standard
3. Enhanced rental platform

These developments mark significant progress in enhancing the ENS ecosystem’s capabilities and user experience.