Thoughts on Decentraland

A decent core idea with a questionable implementation.

First, to really appreciate this blog post, you should understand the Decentraland whitepaper. I’ll wait. You can read their website for some buzzwords if you’re interested in that.

TLDR; the proposed protocol exerts too much control over content (ironic) and includes a meaningless protocol token and artificial economy (cash grab?), but is based on some decent ideas. I provide an alternative vision that leverages web standards and a more open protocol.

Decentraland Whitepaper Summary

Well here’s a summary, regardless of whether you read the whitepaper or not.

Overview

“Decentraland” can be broken down into a few separate concepts:

1. A distributed hash table of “land” coordinates to content (map[(x, y)]content_hash),
2. A “browser” for this content; the browser will render a 3D scene, displaying the correct content at position (x, y) according to that distributed hash table. This is the client app that users will download.
3. A Protocol Token (MANA) that people burn to acquire the rights to a piece of land and can use as a standard ERC20 token for exchange of value.
4. A scripting language used to evaluate the content at a piece of land. The scripting language, executed client-side, will include APIs for physics, playing sounds, micropayments, etc. All content, experiences, games, and interactions are defined using this scripting language.
5. A Real-Time P2P Communication layer using third-party bootstrap servers, provided by land owners, most likely using existing protocols like WebRTC.
6. An identity system, potentially backed by uPort or similar.
7. An author-consent tracking system for identifying pirated content.

This results in a system where land-ownership is decentralized, content and content-distribution is decentralized, and most communication is done over a p2p network, plus all of the benefits that those smart contracts get by running on Ethereum.

cc Decentraland; let me know if I’ve misinterpreted the ideas laid out in the whitepaper.

First, the ideas from the whitepaper that I like:

Decentralized Registry of Land Ownership

Nothing wrong with this concept, I think it’s great. It’s a simple extension of the “track ownership of value using Tokens” where in this case the token is “land”.

The team demonstrated this concept in the “bronze age” which is just a fun word for their alpha version.

Decentralized Distribution of Content

Nothing wrong with this concept. Leveraging IPFS or a similar decentralized storage network is a great way to decentralize content. It comes with its own benefits and tradeoffs, but those have been well discussed.

Adjacency of Content

The fact that content can now be placed “adjacent” to other content simply adds another dimension to the experience of browsing. It’s exciting to see how theory around real-life neighborhoods would translate to this decentralized space. This concept has already been explored in other virtual worlds, though, so it’s not exactly novel, but the decentralization might add an interesting organic factor.

Neighborhood Value

The adjacency rule for land ownership (purchased land must be adjacent to a previously purchased parcel) strongly favors early purchasers and creates a market that empowers squatters. This would ordinarily be a huge Bad Thing™, but if that initial central location becomes inundated with low quality experiences (ads, squatters, etc), the central location will organically materialize elsewhere, just as the “popular neighborhood” organically cycles through a city. Therefore it’s in a cluster’s interest to provide a balance of content that results in a net positive experience. Again, not exactly novel, but a solid concept.

And now the parts I have critical thoughts on:

The Protocol Exerts Too Much Control

The protocol is simply too specific in how users should interact with content and experiences within decentraland. I hope the irony of this is evident.

“Open Standards”

The website describes decentraland as “a virtual world that runs on open standards”. While this sentence is certainly true (in that the standards are open), it betrays the fact that the protocol defines its own standards as opposed to using existing and already-implemented ones that serve the protocol’s needs just fine.

Barrier to Entry re: Scripting Language

EDIT: After joining the decentraland slack community, I learned more about the implementation details (and more about what implementation details still have yet to be known). See the bottom of this article for details.

You’re a developer that built some sort of decentralized experience (dapp); let’s imagine it’s a decentralized poker game using ERC20 tokens. Your service works in the web browser by leveraging, say, AFrame to display a 3D poker table and WebRTC to communicate between players in the room. You run a WebRTC bootstrap node to help connect users in a room. Moves and bet settlement is handled by your smart contracts on Ethereum, so users don’t have to trust you to handle their money or resolve games.

Now you hear about decentraland and want your experience to be available to users. You purchase a parcel of land, but then you realize, for your experience to work in decentraland, you need to re-write the entire thing in their made up scripting language so that clients will execute it. Yeah, how about no.

This “let’s invent a scripting language to define arbitrary 3D content” proposition is a ludicrous undertaking and enforces an absurd barrier to entry for anyone that wants to generate content. While the scripting language is an “open standard”, it is not an existing open standard of which there are many. The development cost of a scripting language for 3D virtual environments is absurdly high, and the phrase

“this scripting language will be designed to handle a wide range of capabilities, including creating objects, loading textures, handling physics, encoding user interactions, sounds, payments, and external calls, among others”

cleverly obscures how much effort will have to go into making a scripting language that is powerful, secure, and doesn’t suck. It also ignores that a standard library will need to be developed, along with high-level physics engines, texture mapping, oh my. Keep in mind that there is literally zero information in the whitepaper about what this language could look like or how it could be implemented, only that it “will exist”.

Why the Scripting Language Exists

The scripting language is part of the protocol because it enables a decentraland client to create a seamless, integrated world of experiences. Because the decentraland client understands this scripting language, you can walk right up to someone’s space (after it’s been loaded) and interact directly with the items they’ve spawned and the physics system that their space implements using that physics system. It’s a pretty concept, but the limitations of a first-party* scripting system quickly negate any benefits. It forces all content to operate in this environment, severely limiting the creative freedom of third-party developers.

It’s honestly absurd that the authors think that their virtual world will be so valuable that companies and content publishers will be so interested in deploying content that they re-implement their entire user experience in this new scripting language of questionable utility.

* first-party in the sense that it’s new and specific to this protocol and not something that already exists with a community around it

Is the Protocol Token (MANA) really necessary?

The protocol token provides two functions:

1. It is burned to purchase land, which tags the value of land to MANA. By burning the MANA, you decrease the supply of MANA (increasing the perceived value) and place an upper limit on how much land can exist.
2. Purchase goods and services within the decentraland ecosystem.

I’d argue that the MANA token isn’t a valuable addition to this ecosystem. There are literally infinite other “currencies” that could be used to satisfy exchanging goods and services.

The only “network costs” that the decentraland protocol needs to absorb are:

• Costs for managing the land hashtable, which can be covered in the cost to execute the land purchase transaction,
• Costs for managing author consent, which are relatively negligible and can be paid by the author, the entity receiving consent, or both,
• Costs for managing the identity system. The whitepaper doesn’t really talk about the identity system, so I can’t make any assumptions here.

The other costs associated with this ecosystem are not native to the protocol:

• Content distribution costs (currently “free”, but handled by the user and the third-party),
• Costs associated with running a p2p bootstrap node (negligible, but also discussed below),
• Costs associated with the actual experience you’re running (can be independently handled by the third-party, discussed below),

All of these can generally be paid for by third parties implementing the protocol. For example, I’d happily run my poker game’s p2p bootstrap node because the profit I make from the game itself is directly tied to how easily users can interact with it (and the other users in the app).

Basically, the protocol doesn’t need a token to incentivize its usage, and you could peg the value of a parcel land to something else (say, Ether) without much change in how it is valued (and this certainly wouldn’t change the value on the secondary market where a parcel of land could be exponentially more valuable depending on its x, y coordinates).

Criticism Summary

The whitepaper proposes both too much and too little at once; too much control over the format of content and how users interact, and too little implementation details and explanation. My mental model of “decentraland” as a system is built from a few assumptions that filled in gaps from the whitepaper, including how the scripting language might work and why it exists; the whitepaper simply has no mention of what this language might look like or why it’s technically needed. I believe this is to exert more control over the implementation of content and obscure the possibility that it might not need to exist at all.

The whitepaper also focuses a lot on the proposed “economy”. The entire upgrade from the “bronze age” to the “iron age” feels like a justification of the MANA protocol token, and an excuse to build an economy, which everyone involved in the project will profit from. There are some influential names attached to this project, though, so I’m hesitant to suggest that it’s a cash grab or similar, but the project does feel like it’s taking advantage of the public’s ravenous desire for ICOs.

It sounds like what the authors actually want, rather than a protocol token, is an app coin that they can use to assign value to transactions within the system, but then that app coin isn’t as guaranteed to be valuable as an integrated protocol token because it doesn’t really need to exist. 😉

My Vision for a Decentralized Virtual Landspace

Instead of focusing on bandwagon nonsense like building a “social” “economic” “platform” for making money, decentraland should focus on making a protocol that anyone can easily use to explore the shared, decentralized registry of “land” while still providing a desirable experience for users. The purpose of the protocol is explicitly to facilitate the exploration of this shared land registry and the content within.

Keep the Land Registry

Honestly the best idea in the whitepaper is the land registry, which is also the simplest to understand and most universally useable. It’s simply a hashtable of what content should be displayed at a specific space in our virtual world.

Scrap the Native Script

Instead of requiring that the content of a space be defined in the first-party scripting language, support web standards and allow content creators to provide any type of web content as “content”. This turns the decentraland client into a “browser” as we understand it today, where it facilitates discovery and usage of third-party content, providing an overall more valuable experience.

To make this a concrete example, my 3D poker app (which is a traditional JavaScript dapp client that interfaces with an Ethereum node), could be hosted at the content_hash related to my space. If a user wants to interact with my content, the decentraland client simply delegates operation to the dapp client, much like opening the app in a new tab or an iframe. In this case, it would use WebVR to render a poker table. You’ll notice that this is basically the exact same concept as a Dapp Browser like Mist or MetaMask. By using web technologies, the browser doesn’t place any additional restrictions on the content it can display.

The Overworld

I’m going to start referring to the virtual world that displays the land within the registry as the “overworld”. This provides a nice distinction between the world that the decentraland client renders and the worlds that third-party content can also optionally create.

Keep the Seamless Overworld

You’ll correctly notice that this removes the ability of the decentraland client to render a seamless overworld; we don’t know what the visual result of rendering a dapp client will be (especially not from the “outside-looking-in”) if we have to defer that rendering to the dapp.

To remedy this and provide the experience of a seamless, never-ending virtual world, the “content” referenced by a space can define, using something similar to the proposed scripting language, some sort of experience that is displayed in the overworld before the third-party dapp is interacted with. This could be a “storefront” 3D model, where the third-party dapp is displayed once the user enters the virtual door, or it could be a 3D poker table with an open seat that launches the poker dapp once the user “sits down” at the table by interacting with it. The important part is that it provides a seamless world while also delegating the actual logic to tried-and-true web technology.

You’ll notice that we haven’t gotten rid of the core experience of walking around a virtual neighborhood in the overworld; that still exists. Additionally, the decentraland client can provide information about the overworld to the space’s rendering logic (like reflection maps), and the rendering script can fetch third-party information like the number of connected users to influence how a space is rendered (by populating a poker table with avatars).

This sort of architecture combines the best of both worlds; a seamless overworld and unlimited creative license to third-parties in how they create their decentraland content.

While we’re at it, we can just call the scripting language JavaScript and request that the content render to WebGL… oh yeah, web standards. Imagine that every piece of land content provided a WebGL scene as part of its content bundle; that scene can be directly integrated into the decentraland client’s WebGL overworld and it all just works because of standards.

obviously there are implementation details to be considered, but this isn’t a whitepaper

Payments

We don’t need to reinvent micropayments. Let the hundreds of other smart people working on that problem handle it for us. Decentraland could leverage the 0x or Swap protocol to handle p2p transactions of ERC23 assets. Make it extremely easy to use, but don’t integrate it into the protocol.

If one of the third-party spaces implements an RPG item as an ERC23 token, it can be traded in any arbitrary manner using one of those protocols for another ERC23-based asset (like ETH or whatever). The economy exists without the need for MANA. In the case of 0x, it would be beneficial for the decentraland foundation to run their own relayer to facilitate matching orders across the ecosystem. This shouldn’t be integrated into the protocol, though, but should exist as a convenient standard to be optionally included in a client.

If a third-party app wants to charge for their services, they can do so in literally any fashion already possible. Again, we don’t need to reinvent the wheel here. The decentraland client should facilitate this transaction ala MetaMask, but, again, should not limit the possibilities by defining them explicitly in the spec.

Implementing the Overworld

One of the neat ideas that I’m excited about with this vision is that the rendering of the overworld (i.e., what does this map[(x, y)]content actually look like), can be deferred to the decentraland client. If the client wants to represent it as an infinite flat plane that you can walk around in, that’s totally reasonable. If it wants to represent the overland as an art gallery where each space is a piece of art on the wall like Mario64, that’s also cool. The important part is that the client satisfies the protocol by facilitating access to the content associated with each land parcel.

A Decentraland client could render third-party content as art on a gallery wall, as long as it fulfills the protocol by facilitating access to the shared state of “land”.

This brings me to another important point; the p2p communication required to render the overworld (i.e., player locations, voice chat, and other interactions) needs to be communicated over some medium. In the whitepaper, the authors suggest that landowners will support these bootstrap nodes. What makes more sense, though, is to have the author of the decentraland client support the bootstrap node; users of a specific decentraland client (say, the infinite-plane client) know for certain that they’ll be able to communicate with users that are running the same client. The cost of hosting a bootstrap node is negligible, and could perhaps be subsidized by donations or a fee for using the client, assuming the client provides value that users are willing to pay for.

By virtue of tying bootstrap nodes and clients together, a decentraland client can assume that everyone a user is connected to is also using a version of that client, and can display a uniform, seamless world.

In a client that allows users to float through 3D space to explore the world instead of being tethered to the ground plane, the client can 1) broadcast a user’s z coordinate and 2) assume that everyone else will be broadcasting one as well.

The separation of client and bootstrap server also has another side effect; by using a different bootstrap server, we can effectively create different “worlds” ala Runescape and WOW; users only interface with other users they’re connected to, but access a shared world state (the land hashmap). This allows for private worlds (host a bootstrap server yourself and tell your friends the password, and now only you and your friends can use it to initiate a p2p connection).

Integration with Space Content

To facilitate an integrated experience, the decentraland client can provide developer-friendly APIs and information to the third-party client like the identity of the user that has entered the space, a texture map of the world “outside” of the space (if you want to render that as a “sky”, for example, so you can “see outside” while inside the third-party experience). The decentraland client can also provide a payments api that third-party content can use. It could present a native prompt for sending an Ethereum transaction (ala MetaMask), allowing third-parties to trade in-game items, purchase content, or otherwise interface with their smart contracts.

To Summarize

The proposed protocol exerts too much control over content, which is ironic as hell, and includes a meaningless protocol token and artificial economy, which might be a concealed attempt to funnel money to the early investors. But the core concept of decentraland is based on some decent ideas.

My vision lays out a much more reasonable protocol for governing the exploration of land based on web technologies, lowering barrier to entry without stripping creative control from third-party experiences and content.

If you liked this analysis, give it a ❤ or @ me in the comments or on twitter dot com.

EDIT: after joining the slack community, I learned more about the implementation details the developers have decided upon.

It seems like the developers have recently settled on using a-frame to describe content, but this isn’t mentioned anywhere else on their blog or in the FAQ (and it seems to be relatively recent, whereas this sort of thing should really have been mentioned in the whitepaper). They also have seemed to agree on considering a decentraland client more of a “browser” for third-party content, which is an acceptable definition. They have definitively not released information on what the “scripting language” will be. The current decentraland client is implemented in Unity Web and is basically a glorified async-rendering 3D scene demo.