Block Parks: Exploring Decentraland scene ownership through NFTs and generative art

Published in

OpenSea

9 min readOct 1, 2019

by Sebastian Hernandez and Sebastian Brocher

TLDR: A Decentraland scene collection with ownership verification. You can explore the collection at Pixura and OpenSea.

The rate of new Decentraland scenes being published to Beta has picked up lately: the first game jam, DCL University course, SDK video tutorials, and the second game jam. Developers who are uploading their scenes to the beta are effectively making public a lot of their hard labor. In theory, it should be possible to write a tool that copies someone’s scene you really like and simply republish that on your own LAND. In other words, land is tokenized but scenes are not.

This gamejam entry, The Block Parks, is one possible way to tokenize scenes: we take a snapshot of a scene and put that information on the blockchain as an ERC-721 token. The data written includes both a screenshot of the 3D scene and the git commit hash of the code/models used to generate that scene. We then put up a PictureFrame of the scene in the scene itself. This 2-step process is called the Sceneception.

Why would you want to tokenize a scene? It’s a way to show that your scene is “original” and not a clone of someone else’s scene. Since we are hosting the Block Parks on a public github repository, it is easy for anyone to simply republish that content on their own LAND. However, since the new LAND owner would not own the PARK token, the PictureFrame would show as not verified, and visitors could therefore tell the scene is not an “original” PARK scene.

Tokenizing scenes is the first step toward enabling a scene market to emerge. A place for LAND owners to go shop for new interesting scenes to populate their land, and for creators to monetize their work. It would even make it possible for the person to “try out the scene” on their own LAND and see how it fits with the surroundings before making a purchase. Only after the token purchase would the scene show as “original”.

This entry is the result of a collaboration between Sebastian Hernandez from The Momus Collective and Sebastian Brocher from ChimiChurri. One day of effort per week from July to the end of the game was dedicated to this project. While many of the ideas in this submission have evolved from the discussions from both Sebs, the programming and artwork is entirely Sebastian Brocher’s contribution.

The parks concept

The Block Parks collection consists of 25 unique parks. The parks share a common structure consisting of:

Four paths: west path, north path, east path, and south path
Four benches: west bench, north bench, east bench, and south bench
Centerpiece: a climbing structure or art centerpiece situated in the square area defined by the paths and built atop a marble floor
Grassy areas: covering the floor from the paths out through the park scene edges

Each park represents a particular block from the history of the Ethereum blockchain as described in the Aetheria Block Museum. Thus, every park represents a significant historical event from the Ethereum history. The event is described through text engraved on the west path.

The art centerpiece or climbing structure encodes the block hash and the block number in an artistic way, more fully described below.

Programmatically generating scenes

Borrowing ideas from generative art — whereas the artist builds a system that generates the art — and other crypto generative art projects such as Autoglyphs, CryptoArte, and the Ms Ethereum series, the scenes are programmatically generated in a fully deterministic fashion.

To do this, a genparks CLI application was built capable of generating parks for a variety of different concepts. The team went through 12 different concepts or ideas before deciding on concept #12 for the current implementation. Each Block Park is generated based on only a few input variables:

The park number
The Ethereum block number
The block’s hash
The block’s given name and description (taken from the Aetheria Block Museum)

First, the application calls the Decentraland SDK to generate an empty scene. Then, it uses a templating system to generate the scene’s code for the selected concept number. The generated code then uses the input data to build the final park scene.

The artwork

The centerpiece artwork projects the block’s hash into a beautiful climbing structure built of 64 stories or floors. Each story has a tile or step and represents a hex digit from the block’s hash so that the first hash hex digit is encoded in the lowest tile from the ground floor, the second digit encoded in the second lowest tile or second floor, and the 64th hex digit is encoded by the highest tile (top floor). Climbing the structure is a fun exercise and gives the user a great view of the scene surroundings.

The area covered by the centerpiece is logically divided into a 4x4 grid, yielding 16 total possible tile placements. Each of these 16 possible placement maps to a hex digit, so that:

Hex digit ‘0’ places the tile on the southwest corner
Hex digit ‘3’ places the tile on the southeast corner
Hex digit ‘4’ places the tile on the second most southerly row and in the westernmost column
Hex digit ‘f’ places the tile on the northeast corner

This gives the parks a deep and meaningful representation of their block, and also creates visually appealing variety as the hashes are unique across parks and tend to have very disperse random properties.

The block number is also represented in the centerpiece through spheres, deterministically placed in specific floors or tiles.

The puzzle

A fun puzzle is also generated and included within each park. Through a minimalistic UX, the user is guided to the basic mechanisms of the puzzle.

To solve the puzzle, the user must click on the spheres in a very specific order, which reveals the method used to encode the block number into spheres radius and placement. Uncovering the exact encoding is left as an exercise to the reader as the puzzle solutions would be otherwise revealed hereby.

Once the user solves the puzzle, an NFT will be displayed at the bottom center of the park, showing whether the LAND owner also owns the scene through the Block Parks NFT contract and as verified by Decentraland’s PictureFrame technology.

The blocks

The identification of historical blocks and writing of description for each entry was completed last Spring for the Aetheria Block Museum project. All information is freely available here for anyone to reuse.

Here’s the list of the block numbers represented through the 25 parks:

# 0, The Genesis
# 1, The Ethereum Frontier
# 762, Oldest One-time Miner
# 88090, The First ICO: Augur
# 515000, DevCon-1: London
# 1000000,One Million Blocks
# 1150000, Homestead Fork
# 1428757, theDAO is deployed
# 1718497, theDAO is drained
# 1920000, theDAO Fork
# 2283416, EXTCODESIZE DoS Attack
# 2290000, DevCon-2: Shanghai, not published
# 2421507, “Suicide Bomb” DoS Attack
# 2463000, Tangerine Whistle
# 2675000, Spurious Dragon
# 3141592, The Most Recent Pi Block, not published
# 4041169, Parity Multisig Public Init Hack
# 4170700, Decentraland MANA sale startBlock
# 4321454, The Terraform Event
# 4370000, Metropolis Byzantium, not published
# 4470000, DevCon-3: Cancun
# 4501969, Parity Multisig Library, not published
# 4605346, CryptoKitty #1 is born
# 4752008, The Birth of DAI
# 6610000, DevCon-4: Prague

The minting

The process of minting a PARK token starts by taking a screenshot of the scene from approximately 1 LAND away at a 45 degree angle with the scene. That screenshot is cropped and resized to 512x512 pixels to produce the token image. A token is then minted in the Block Parks collection on Pixura. In the ERC-721 metadata, along with the image, we include the hash of the latest git commit as a way to associate the scene with an exact set of code, model and configuration files. The token is then submitted to OpenSea, after which it can be whitelisted by the Decentraland team.

Here’s the resulting block parks assets collection at OpenSea.

What’s next?

The ideal user experience for buying a scene would be to go into a new Scene section on https://market.decentraland.org, find an interesting scene and one-click to preview it on her own LAND as an unverified scene. All this could be done from the browser, with no need for CLI or files. This market could also be hosted as a scene in Decentraland itself instead. Once someone identifies a scene they want to own as “original”, they complete a blockchain transaction and their scene starts showing as “original” in the HUD.

The Sceneception solution we presented is not perfect. Here are some issues that remain to be addressed:

1. Someone could copy the scene NFT information into their own contract, and manage to get the Decentraland team to whitelist that other contract. A currently whitelisted contract could also be highjacked (keys stolen) and used by someone to make copies of verified scenes. There’s a need for a robust and transparent whitelisting process for PictureFrame, with a clear plan toward decentralizing this process. Eventually there might also be a need for a per-NFT blacklist process to cover the case where a whitelisted smart contract is highjacked.

2. There’s no actual link between the PARK and LAND tokens on the blockchain. This means it’s impossible to tell where a given scene is currently published or whether it is even published at all. We are currently adding in the description the “Initial Location” and “Initial Viewpoint” where the screenshot was taken, but this will break as soon as a scene is moved to a different LAND. A more generic SCENE token could be created and the LAND contract updated to link a scene and a land dynamically. When a scene would be published by a user, if the scene is tokenized then the LAND token updates to start pointing to the new SCENE token and vice-versa.

3. Should there be a single official Decentraland SCENE contract? The alternative is the proliferation of privately-owned individual scene contracts (like PARKs). Having an official SCENE token just like we have an official LAND token would allow for tighter integration between the tokens at the smart contract level but also in the client. If so, the path toward full-decentralization of that Scene contract should be clear from the start.

4. It’s unclear how remix should be treated in this system. To maximize large coverage of high-quality content, we should make it easy to share models and scenes and to reuse other people’s work. But how much modification to a scene must happen before someone can call it their own remix and mint a new SCENE token? Would it be fair if someone simply added basic models to Block Parks (such as people sitting on the benches), minted their new SCENEs and started selling them? What if someone reused Block Parks, but significantly improved any or all elements of the scenes? Then it would seem fair that they could sell their work. One solution might be to add one step to the SCENE minting process, where the user can provide a license agreement link — or known license type, e.g.: Creative Commons Attribution (CC BY) — , and attribution to another SCENE. The attribution could be used in a marketplace to share revenue among contributors to the scene sold.

5. What are the best visual cues for “original” scenes? A simple mark in the HUD? A mark in the minimap?

6. How to avoid people just spamming the SCENE registration contract with stolen content such as scenes that are already deployed? There could be a pre-registration of SCENEs at a given block number. In terms of removing spam (or low-effort content) from an eventual SCENE marketplace, a curation market like the Meme Factory could be developed. A percentage of the SCENE sales could go back to curators as an incentive to curate.