Name Bazaar - Technical Overview

By Matúš Lešťan, Co-Founder of district0x

 

On October 24th, the district0x team released Name Bazaar, a peer-to-peer marketplace for the exchange of names registered via the Ethereum Name Service. So far, the market has been operating smoothly and we have received lots of positive feedback, so in this post I’d like to share some of our design decisions and give an in-depth look into how Name Bazaar actually works under the hood.

Smart Contracts

As you’ve might have guessed, at the core of Name Bazaar are Ethereum smart-contracts. Here’s a simplified diagram of the high-level architecture of its smart-contracts.

An offering is simply a smart-contract that coordinates a single trade of an ENS name in trustless manner. Currently, we support two types of offerings: Buy Now, for fixed price trades, and auctions.

• OfferingRegistry: A central smart-contract that is notified every time a new offering is created or an existing offering changes state. This primarily helps our server to keep track of all offering related events happening on the blockchain. The OfferingRegistry also serves as an emergency break, where by triggering the pause function with our emergency multisig wallet, we can pause trading on all deployed offering contracts at once in the event a critical vulnerability was found. In this case, ownership and funds would be returned to the original owners one by one.

• AuctionOfferingFactory, BuyNowOfferingFactory: These contracts are used to deploy new offering contracts to the blockchain. These deployed contracts don’t contain any real logic, they’re simply proxy contracts forwarding all function calls to ‘real’ offering contracts, but still storing state. Thanks to this, creating an offering is very gas efficient and code is not duplicated on the blockchain. To learn more about this pattern, check out Proxy Libraries in Solidity by Manuel Araoz.

• Forwarder: A very thin proxy smart-contract, that delegates all calls to either AuctionOffering or BuyNowOffering. Our pre-Byzantium implementation was borrowed from Aragon’s repository, so kudos to our friends there!

• AuctionOffering, BuyNowOffering: These contracts contain offering logic, that forwarders delegate calls into. These are deployed only once, by the district0x team.

Apart from these contracts, Name Bazaar utilizes a few others, not critical for trading:

• OfferingRequests: This contract keeps track of user addresses that requested a name for sale, so we have an indication of the most demanded names, and allows us to notify them by email once a requested name gets offered.

• DistrictEmails: A very simple contract where users can associate their address with their encrypted email for receiving notifications. Only our email server can decrypt email addresses. The plan is to reuse this contract for all of our districts, so users don’t need to set it for each one. When a more robust solution comes to the mainnet, such as uPort, we’ll switch to that.

If you want to see a full list of Name Bazaar’s smart-contracts, you can find them here.

System Architecture

Name Bazaar has a semi-decentralized architecture consisting of 3 main components.

Server

Our server syncs up with the blockchain and builds an in-memory database of offerings in a search-friendly format. Then, the UI can make requests to the server such as “Give me 10 offerings starting with ‘car’ ordered by most expensive”. It is impossible to make such requests directly to blockchain. The server always returns only offering addresses, then the UI loads the offering data directly from the blockchain. This helps us to reduce server load and is also a bit more decentralized.

With that being said, in the future we plan to make the server syncing code also loadable in the UI, so users who run a blockchain node locally will be able to switch into “full decentralization mode” and build a search-friendly database in a background of their browsers, not relying on our servers at all. For users who care less about decentralization, there will always exist the convenient option to just connect to our servers. We plan to adopt this model for all districts, not only Name Bazaar.

For our server code we use Clojurescript compiled into Node.js and for our in-memory database we currently use sqlite3.

UI

At district0x, we take special care to deliver a flawless UX and eye-pleasing UI. Given such, most of Name Bazaar’s codebase is, in fact, UI code.

With Name Bazaar, we introduced the Transaction Log, a convenient panel located near the top-right corner of the interface that keeps track of user’s transactions, displaying useful information such as human-readable descriptions of actions taken on the platform. This helps users stay informed about state of their transactions, eliminating the need to wait for a transaction to be processed to be able to interact with the UI further.

For UI code we use Clojurescript, with ReactJS and SemanticUI under the hood. Our UI files can always be accessed via IPFS here, as well as via our server.

Blockchain

All user data is stored only on the blockchain, either in form of events or state data. Current features of Name Bazaar do not require storing large pieces of data, therefore, an IPFS integration is not yet needed.

Further Development

Giving a sneak peak into future of Name Bazaar, here is a list of the major features being prepared, in chronological order:

• Registration of new ENS names
• Management of owned ENS names
• Comment system for easier price negotiations
• Promoted offerings

That’s it for our high-level overview Name Bazaar’s technical details. If you would like to learn more, feel free to dig in our code at Github or reach out to our team on Rocket Chat or Telegram.

Learn More

For more information about the district0xNetwork:
Check out our white paper
Watch our introduction video
Subscribe for email updates
Follow us on Twitter
Join us on Telegram
Subscribe to our subreddit
See our live stream recaps on YouTube