Decentralization is a tricky concept. What does it mean to be decentralized exactly? You may get ten different answers if you ask ten different people.

Here is ours:

Decentralization is about control.

Does one player have control?

This definition is equally nuanced. If there are multiple pieces to a puzzle, each piece may need to be evaluated separately. The gray area surrounding discussions of decentralization is why analyzing the decentralization of crypto-projects is so challenging.

Darkblock is no exception. Each facet of our protocol layer must be scrutinized for any form of central control. To understand our steps towards a fully decentralized operation, we need to get into the weeds and inspect each component of Darkblock. Some aspects are inherently decentralized by leveraging existing decentralized systems, others require additional explanation.

To understand how we get to decentralization, we first need to understand what Darkblock is and how Darkblock works.

The Darkblock protocol enables access controls based on NFTs. To be more specific, we give creators the ability to encrypt a piece of content and control access to it with an NFT. Whoever owns the NFT linked to the Darkblock can access the content.

A creator making a Darkblock must first reach out to the Darkblock network to create an encryption key. The key needs to be generated and stored in a decentralized way, all while maintaining security and redundancy. Each part of this process must be decentralized.

Content Security

Darkblock uses AES-256 encryption, which is very secure, but we also need to securely handle the encryption keys to decrypt and deliver the content. Each of the nodes in our network must be able to securely handle these keys of the content without the node operators having access to the keys or the content. We want anyone to be able to power this protocol, so security is a big concern! While we don’t have an ETA for this piece of the puzzle, we are analyzing avenues that will allow us to achieve our goals quickly with scalability.

In regards to protection of the encryption key, there are several viable solutions, many of which leverage Trusted Execution Environments (TEEs). Options include rolling out our own software to run in a TEE, or incorporating an existing platform that utilizes TEEs to run code securely, such as Integritee, Phala, or The Secret Network. We are also evaluating proxy re-encryption technologies such as Nucypher, and while there are some techniques to split up encryption keys amongst multiple nodes to prevent any one node from being given access, we think that ultimately construction of those keys may require TEEs to make the network optimally secure.

Storage

The permanence of data stored in Arweave is a natural fit for NFTs, which is why we chose Arweave to store Darkblocks. Arweave is about as decentralized as it gets, but has centralized points of entry that we need to leverage, such as the arweave.net gateway. The gateway enables the query of the Arweave metadata in ways that are critical to the function of Darkblock. But the gateway is controlled by the Arweave organization, and though it is extremely unlikely that they would do anything untoward, the centralized issue remains. Darkblock could run its own gateway, but if there is only one gateway operating the entire protocol, it would be centralized. Luckily, the Arweave team is working hard to decentralize gateways, and incentivize people to run them independently.

Darkblock Creation

It is possible (but challenging) to build your own Darkblocks implementing our spec. We offer an API for partners to make this easier, but we plan to enable this feature for all users to operate directly and without our permission. Specs will be published on this soon, as well as SDKs to make it (nearly) as simple as using our API. This process will involve generating an encryption key via a request to one node in the network, encrypting your data with that key, wrapping the data in an Arweave transaction with appropriate metadata, and pushing it up to Arweave. That’s it! But the encryption part is tricky though and easy to get wrong.

NFT data: Who owns that NFT?

Most APIs to retrieve metadata about an NFT are centralized. Many projects use the OpenSea or Rarible APIs to display NFT metadata to users. Even Twitter uses OpenSea’s API.

But what if those APIs decided to block certain NFTs for some reason?

What if they simply didn’t work?

What if they decided to implement new logic that didn’t jive with the rest of the community?

We need a decentralized way to determine who owns an NFT. There are a few projects tackling this; Unmarshal.io and TheGraph.com. Both are still in early stages, but as they mature, we can increase our reliance on them. A protocol is only as decentralized as the data it uses. In our case, the data has the power to control who has access to content. We are targeting Q2 2022 for integration with a decentralized NFT data service. Before we make this leap, we will need to be certain of the service’s maturity and whether they can support the features we need.

The switch won’t be inconsiderable, and we will probably need to take one chain at a time. Ethereum is the lowest hanging fruit due to its early adoption and gravity as a top NFT chain. It is natural that projects like Unmarshal and TheGraph focus their attention there. However, we aim to incorporate decentralized data sources for other chains as they become available.

The Darkblock Viewer

The Darkblock Viewer is a piece of javascript code that enables people to embed a Darkblock into any website, much like a YouTube embed. The code is currently served by Darkblock controlled servers (via Cloudfront for speed), but we are having an internal debate over whether this needs to be decentralized or if open source is sufficient. We are also creating an NPM package for the viewer. Is an open source, optional viewer decentralized enough? We aren’t sure! Let us know your thoughts (chat.darkblock.io).

Another avenue we are exploring is the enhancement of content protection via the widget. This would require a more secure handshake between the widget and the server it is served from. ICP, or a similar [TBD] platform might provide our answer. Perhaps the protocol nodes themselves are enlisted to serve the widget or widgets are served via Arweave (using Smartweave to version the code). One option is to have a DAO control software releases to ensure oversight into this process. Each option is not simple or self-explanatory. Some require pieces absent in Darkblock’s core mission that have not been developed elsewhere yet. Perhaps the solution is something else entirely.

Conclusion

As you can see, creating a fully decentralized protocol is not an easy task. Each part of the project (security, storage, creation, verification, widgets) must be critiqued independently to verify the absence of any centralized components.

While we hope this reflection serves as a tool to educate the NFT community on the intricacies of creating a fully decentralized crypto-project, we also hope it generates user feedback for our protocol. Darkblock is committed to transparency at every stage of our project. We want to maintain an open and honest dialogue with our users and the community to guarantee we are creating something not only useful, but in demand.

There is still a lot to be done to make Darkblock fully decentralized, but we think the juice is worth the squeeze. What about you?